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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3 GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document defines the Stage 2 description for the Local Call Local Switch feature. Local Call Local Switch 
may be implemented in both BICC based CS core networks as defined in 3GPP TS 23.205 [2] and SIP-I based CS core 
networks as defined in 3GPP TS 23.231 [3], with a GSM/EDGE Radio Access Network supporting either TDM based 
or IP based A interface. 

This stage 2 shall cover the information flows between the GMSC server, MSC server and media gateways that are 
required to support Local Call Local Switching highlighting the specific requirements in addition to those defined for 
BICC based CS core networks 3GPP TS 23.205 [2] and SIP-I based CS core networks 3GPP TS 23.231 [3]. Note that 
nothing in the present document shall preclude an implementation of a combined MSC Server and MGW. The present 
document shall show the CS core network termination of the A interface, and the information flows between the ESS 
and the MSC server, in order to cover the information flow stimulus to the core network and describe the interaction 
with the supplementary and value added services and capabilities. 
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3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TR 21.905 [1] and the following apply. A 
term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905 [1]. 

BSS ID: A globally unique identifier of a Base Station Subsystem (ESS). 

call leg: The access link between the mobile station and the Core Network. A mobile to mobile call consists of two call 
legs and the link through the Core Network. 

call leg correlation: The process within the BSS to search for the other call-leg(s) of a (potential) Intra-BSS call by 
appropriate means. 

intra-BSS call: A mobile to mobile voice call involving two mobile stations connected to the same BSS. 

intra-BSS call detection: Determination that both call legs are within the same BSS. 
local call: An Intra-BSS call that can be locally switched by the BSS. 

locally switched call: A local call with a direct local path between the Call-legs, switched by the BSS. 

3.2 Symbols 

For the purposes of the present document, the following symbols apply: 

A Interface between the BSC and the MSC-S 

Abis Interface between the BSC and the BTS 

i intermediate node prefix. 

Mc Interface between the (G)MSC-S and the MGW. 

Nc The NNI call control interface between (G)MSC servers 

o originating side prefix, e.g. oUE, oBSS, oMSC, oMGW for nodes and e.g. oA-interface, 

oAssignment Request etc for interfaces, messages etc. 
t terminating side prefix , e.g. tUE, tBSS, tMSC, tMGW and e.g. tA-interface, tAssignment Request 

etc for interfaces, messages etc. 

3.3 Abbreviations 

For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
TR 21.905 [1]. 

AoIP A over IP, using IP as the bearer of the user plane of A interface 

AoTDM A over TDM, using TDM as the bearer of the user plane of A interface 

APM Application Transport Mechanism 

COT Continuity message 

GCR Global Call Reference 

LCLS Local Call Local Switch 

OoBTC Out of Band Transcoder Control 



IVIain Concepts 



4.1 General 

Local Call Local Switch provides the capability for the user plane to be locally switched (e.g. voice data in user plane is 
not backhauled to the CS core network) for calls that are generated and terminated by users that are served by the same 
BSS. The result is saving on transmission resource of the Abis and/or A interface. 
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Local Call Local Switch shall only be considered for a CS voice call and is transparent to the end user. 

Figure 4.1.1 shows an example of Local Call Local Switching. It highlights only the main nodes and interfaces and 
differentiates between "originating" nodes and interfaces (oUE, oBTS, oMSC, oMGW, oAbis, oA) and "terminating" 
nodes and interfaces (tMSC, tMGW, tBTS, tUE, tAbis, tA). It also includes an Intermediate MSC server and MGW 
(iMSC, iMGW), which may be a (G)MSC server or other intermediate CN control node and its MGW. 



rwi 



Speech 
Signaling 

iMSC 




tBTS 



(with local switching 
Capability) 



"^scO 



Figure 4.1.1: Example of Local Call Local Switching 

The "active" User Plane path is shown with a thick, solid blue line for the case that Local Switching is provided 
between two BTS's, while the "inactive" User Plane path, i.e. the two Abis-links, the two A-links and the links within 
the Core Network are not carrying traffic and are therefore marked with thin, dotted blue lines. The Control Plane paths 
are shown in solid red lines. 

Local Call Local Switch is attempted to be instantiated during call establishment. During this phase, negotiation for 
support of LCLS is performed within the Core Network and requests to correlate and connect the call legs are made to 
the BSS when LCLS is successfully negotiated. Interaction with existing supplementary services and 
handover/relocation are supported. Depending on the scenario this may require a break of an existing locally switched 
call where the voice data on user plane shall be routed via the core network, or a (re)establishment of a locally switched 
call where the voice data on user plane shall be locally switched in the BSS. 

Local Call Local Switch may be supported on both TDM based A interface (AoTDM) and IP based A interface (AoIP). 

Local Call Local Switch may be implemented on both a BICC based CS core network and a SIP-I based CS core 
network and therefore the main concepts that are defined within 3GPP TS 23.205 [2] and 3GPP TS 23.231 [3] 
respectively, also apply to Local Call Local Switch. 

The MSC server is in charge of call control, supplementary services and gives permission (or denies) as to whether 
local switching may be applied. When the MSC server has granted the permission to apply LCLS, the BSC makes the 
final operation decision whether to establish LCLS (dependent on alignment of codecs, BTS's supporting local 
switching, resource available, status of its BTS's, the state of its radio legs). 

4.2 LCLS Negotiation 

4.2.1 General concept of LCLS negotiation 

LCLS negotiation is required within the Core Network in order to determine if all of the MSC servers and intermediate 
nodes, including GMSC servers, in the call control path allow the support of the LCLS functionality. LCLS negotiation 
may result in LCLS not being permitted for the following reasons: 

- An MSC server node or intermediate node, including GMSC server node, has not been upgraded to support the 
LCLS functionality. 

- It is prevented due to specific interactions e.g. Supplementary Services, operator determined restriction of LCLS, 
etc. 
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Additionally the LCLS negotiation may result in local call local switch being permitted but with certain configurations 
for user plane connectivity to the BSS depending on the network requirements, for example periodic signalling of pre- 
paid tones. 

The LCLS Negotiation Information Element is explicitly signalled on the Nc Interface. The LCLS Negotiation (request) 
IE is signalled during call establishment where the originating MSC server starts LCLS negotiation. 

Depending on the support of LCLS, the MSC servers and intermediate nodes, including GMSC server, may remove the 
LCLS Negotiation (request) IE from further signalling on the Nc interface (e.g. if node does not support LCLS) or 
modify the contents of LCLS Negotiation (request) IE (e.g. if LCLS is not allowed for the subscriber or if bicasting is 
required). 

The following properties are signalled in the LCLS -Configuration-Preference Information Element for "LCLS 
Allowed" to allow each node to indicate what level of user data connection it requires: 

- Need_Receive_Forward = No/Yes; this indicates if the node needs to receive UL data from the originating UE. 

- Need_Receive_Backward = No/Yes; this indicates if the node needs to receive UL data from the terminating UE. 

- Need_Send_Forward = No/Yes; this indicates if the node needs to insert user data toward the terminating UE. 

- Need_Send_Backward = No/Yes; this indicates if the node needs to insert user data toward the originating UE 

The default setting is "No" meaning that no Core Network user data requirement exists. If a node receives any of the 
parameters set to "Yes" within LCLS Negotiation (request) IE it shall not change them; it may however change any 
parameter to "Yes". The received parameters of the LCLS Negotiation Response IE shall not be modified. 

The LCLS configuration preference that is negotiated on the core network path allows the oMSC server and the tMSC 
server to request the correct LCLS configuration from the BSS (see sub-clause 4.6.2) on the originating and the 
terminating leg. 

Table 4.2.1.1 shows all possible LCLS configuration preferences and the related LCLS configurations requested from 
the BSS on the originating and the terminating leg. 
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Table 4.2.1.1 : Final LCLS configuration preference negotiated on the Core Network path and the 
related LCLS configuration requested from the BSS 





Negotiated configuration preference of LCLS 
Negotiation IE 


Resulting LCLS 

configuration requested 

from oMSC to oBSS 


Resulting LCLS 

configuration requested 

from tMSC to tBSS 


Need_ 
receive_ 
forward 


Need_ 

send_ 

backward 


Need_ 
receive_ 
backward 


Need_ 

send_ 

forward 


1 


No 


No 


No 


No 


connected both-way in the 
BSS 


connected both-way in the 
BSS 


2 


No 


No 


No 


Yes 


connected both-way in the 
BSS 


connected both-way in the 

BSS and send access DL 

from the Gore Network 


3 


No 


No 


Yes 


No 


connected both-way in the 
BSS 


connected both-way in the 

BSS and bi-casted UL to the 

Gore Network 


4 


No 


No 


Yes 


Yes 


connected both-way in the 
BSS 


connected both-way in the 

BSS and bi-casted UL to the 

Gore Network and send 

access DL from the Gore 

Network 


5 


No 


Yes 


No 


No 


connected both-way in the 

BSS and send access DL 

from the Core Network 


connected both-way in the 
BSS 


6 


No 


Yes 


No 


Yes 


connected both-way in the 

BSS and send access DL 

from the Gore Network 


connected both-way in the 

BSS and send access DL 

from the Gore Network 


7 


No 


Yes 


Yes 


No 


connected both-way in the 

BSS and send access DL 

from the Gore Network, block 

local DL 


connected both-way in the 

BSS and bi-casted UL to the 

Gore Network 


8 


No 


Yes 


Yes 


Yes 


connected both-way in the 

BSS and send access DL 

from the Gore Network, block 

local DL 


connected both-way in the 

BSS and bi-casted UL to the 

Gore Network and send 

access DL from the Gore 

Network 


9 


Yes 


No 


No 


No 


connected both-way in the 

BSS and bi-casted UL to the 

Gore Network 


connected both-way in the 
BSS 


10 


Yes 


No 


No 


Yes 


connected both-way in the 

BSS and bi-casted UL to the 

Gore Network 


connected both-way in the 

BSS and send access DL 

from the Gore Network, block 

local DL 


11 


Yes 


No 


Yes 


No 


connected both-way in the 

BSS and bi-casted UL to the 

Gore Network 


connected both-way in the 

BSS and bi-casted UL to the 

Gore Network 


12 


Yes 


No 


Yes 


Yes 


connected both-way in the 

BSS and bi-casted UL to the 

Gore Network 


connected both-way in the 

BSS and bi-casted UL to the 

Gore Network and send 

access DL from the Gore 

Network, block local DL 


13 


Yes 


Yes 


No 


No 


connected both-way in the 

BSS and bi-casted UL to the 

Gore Network and send 

access DL from the Gore 

Network 


connected both-way in the 
BSS 


14 


Yes 


Yes 


No 


Yes 


connected both-way in the 

BSS and bi-casted UL to the 

Gore Network and send 

access DL from the Gore 

Network 


connected both-way in the 

BSS and send access DL 

from the Gore Network, block 

local DL 


15 


Yes 


Yes 


Yes 


No 


connected both-way in the 

BSS and bi-casted UL to the 

Gore Network and send 

access DL from the Gore 

Network, block local DL 


connected both-way in the 

BSS and bi-casted UL to the 

Gore Network 
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Negotiated configuration preference of LCLS 
Negotiation IE 


Resulting LCLS 
configuration requested 


Resulting LCLS 
configuration requested 


16 


Yes 


Yes 


Yes 


Yes 


connected both-way in the 

BSS and bi-casted UL to the 

Core Network and send 

access DL from the Core 

Network, block local DL 


connected both-way in the 

BSS and bi-casted UL to the 

Core Network and send 

access DL from the Core 

Network, block local DL 



A Core Network node can optionally request that its related MGW isolates the access side termination from the network 
side termination in order to avoid any forwarding of data that it receives from another network entity (Core Network 
node or BSS). Isolation of the access termination is possible when user data need not be transported from the oBSS or 
the tBSS through the complete core network and in this case the LCLS configuration, which is sent to the oBSS or the 
tBSS based on the final LCLS configuration preference does not include the request to block local DL user data. 

Figure 4.2.1.1 shows an example of how the user plane data can be configured as a result of the CN LCLS Negotiation. 
The precise LCLS configuration settings for each permutation of LCLS Negotiation options are specified in Table 
4.2.1.1. 




UE-o 



UE-t 



Figure 4.2.1.1 : General concepts for LCLS configurations as a result of LCLS Negotiation. 

Annex A provides further examples of LCLS negotiation in the CN and LCLS configuration in the BSS. 

4.2.2 (void) 

4.2.3 (void) 

4.2.4 General concept of LCLS Configuration Preference Modification 

LCLS Configuration preferences may be modified during an ongoing call. 

The LCLS -Configuration Change Request message may be signalled mid-call to attempt to establish LCLS or modify 
LCLS configuration preferences, for example for mid-call tones or announcements. Any core network node that 
requires change of the LCLS configuration preferences may initiate the LCLS Configuration Change Request. 

Change of the LCLS configuration preferences may only be initiated after Answer. 
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NOTE 1 : prior to Answer message being returned the call is considered to be in the set-up phase and then 

subsequent LCLS Negotiation Response lEs can be sent within the call establishment messages (e.g. 
APM, ACM, CPG). 

Only after the node has already handled LCLS Negotiation procedure may it initiate a Change of the LCLS 
configuration preferences. If a node does not respond to the LCLS Negotiation then it shall not trigger a change of the 
LCLS configuration preferences at a later time in the call. 

NOTE 2: Take Call Waiting for example, the call will trigger an LCLS Negotiation towards the called party since it 
is a call establishment from the calling parties perspective. 

When receiving the LCLS Configuration Change Request message, the other nodes can only accept or reject the request 
without any modifications. If another node wishes to make further changes to the LCLS configuration preference 
settings it can initiate its own modification of the LCLS Configuration Preference IE settings after the ongoing change 
of the LCLS configuration preference procedure is completed. 

The initiating node shall signal the LCLS Configuration Change Request message in the direction (originating leg or 
terminating leg or both - but only for Intermediate Node) that it requires the LCLS configuration preference settings to 
be changed. 

If the intermediate node receives the LCLS Configuration Change Request message and it does not accept the requested 
changes to the LCLS configuration preferences it shall immediately return LCLS Configuration Change Request Result 
message indicating the same requested LCLS Configuration Preferences IE settings and with the LCLS Configuration 
Change Result Code IE indicating rejection of the requested LCLS configuration change. Otherwise if the intermediate 
node accepts the requested changes to the LCLS configuration preferences it shall forward the received LCLS 
Configuration Change Request message containing the LCLS Configuration Change Request IE and the LCLS 
Configuration Preference IE to its subsequent (succeeding/preceding) node. 

If the node which terminates the LCLS Configuration Change Request is the oMSC server or the tMSC server and it 
accepts the requested changes to the LCLS configuration preferences it shall return LCLS Configuration Change 
Request Acknowledge message indicating the same requested LCLS configuration preferences and with the LCLS 
Configuration Change Result IE indicating acceptance of the LCLS Configuration Change Request. 

If the node which terminates the LCLS Configuration Change Request is the oMSC server or the tMSC server and it 
does not accept the requested changes to the LCLS configuration preferences it shall return LCLS -Configuration 
Change Request Acknowledge message indicating the same requested LCLS configuration preferences and with the 
LCLS Configuration Change Result IE indicating rejection of the LCLS Configuration Change Request. 

On receipt of the LCLS Configuration Change Request Acknowledge message from the succeeding/preceding node the 
intermediate node shall forward it to its subsequent (preceding/succeeding) node. 

The change of the LCLS configuration preferences procedure is completed: 

- for the node that receives the LCLS Configuration Change Request message when it sends the the LCLS 
Negotiation Request Acknowledge message; 

- for the node which initiates the LCLS Configuration Change Request when it receives the LCLS Configuration 
Change Request Acknowledge message. 

NOTE 3: If the node which initiates the LCLS Configuration Change Request receives the LCLS Configuration 
Change Request Acknowledge with the LCLS Configuration Change Result IE indicating rejection the 
node can trigger an LCLS Break as described in sub-clause 7.2.1, specific applications such as insertion 
of tones or announcements will dictate this and are described in subsequent sections. 

If LCLS Negotiation has occurred during call establishment and a handover occurs prior to answer which changes the 
LCLS configuration preferences (from a previously agreed "No" to a "Yes") then the node shall wait until after Answer 
before requesting the modification of the LCLS configuration preferences. 

NOTE 4: Inter-MSC Handover during call establishment can result in an outstanding I AM - oMSC has sent I AM 
forward and then performs Inter-MSC Handover - which could result in the LCLS configuration 
preferences being out of alignment prior to Answer, the MSC can then defer sending the LCLS- 
Connect_Control request to its BSS if it wishes to prevent LCLS until it has performed a modification of 
the LCLS configuration preferences. 
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4.3 LCLS Call Leg Correlation 

4.3.1 General 

LCLS call leg correlation is required in order to allow the BSS to identify that two call legs that are part of the same call 
are within the same BSS, and therefore can be correlated together to be a candidate for Local Call Local Switching. 

The originating MSC server shall generate a Global Call Reference (GCR) Information Element which is a globally 
unique call identifier for the duration of the call and needs to be sent to all nodes in the routing path. The Global Call 
Reference is further detailed within clause 1 1 . 

The originating MSC server and the terminating MSC server shall include the GCR Information Element in the 
ASSIGNMENT REQUEST and HANDOVER REQUEST messages. 

See Clause 6 for the detailed descriptions and related call flows for the call establishment procedures. 

The GCR may additionally be signalled within the core network for supplementary service interaction with LCLS and 
Inter-MSC Handover, this is further detailed in Clause 13 and Clause 8 respectively. 

On receipt of a GCR Information Element, if the BSS supports LCLS, the BSS shall store the GCR for each call leg 
until the call is released or that call leg is handed over to another BSS. 

NOTE: the inclusion of the LCLS-BSS-Status IE in the response indicates to the MSC server that the BSS 
supports LCLS. 

If the GCR and LCLS -Configuration Information Elements are included in the ASSIGNMENT REQUEST message, 
without the LCLS -Correlation-Not-Needed Information Element (see optional Intra-Network Detection, Sub-clause 
4.3.2 and optional Intra-BSS Call Detection, Sub-clause 4.3.3), the BSS shall perform call leg correlation and send the 
LCLS-BSS-Status Information Element with the correct value within the ASSIGNMENT COMPLETE message. 

If the GCR and LCLS -Configuration Information Elements are included in the HANDOVER REQUEST message, the 
BSS shall perform call leg correlation and send the LCLS-BSS-Status Information Element with the correct value 
within the HANDOVER COMPLETE messages. 

If the GCR, LCLS -Configuration and LCLS -Correlation-Not-Needed Information Elements are included (see optional 
Intra-Network Call Detection, Sub-clause 4.3.2 and optional Intra-BSS Call Detection, Sub-clause 4.3.3) in the 
ASSIGNMENT REQUEST message, the BSS shall either: 

- not perform any call leg correlation, but only store the GCR for the assigned call leg and send the LCLS-BSS- 
Status Information Element with the value "Call Not Possible to be Locally Switched" within the 
ASSIGNMENT COMPLETE; 

or 

- ignore the LCLS -Correlation-Not-Needed Information Element, store the GCR and perform call leg correlation, 
and send the LCLS-BSS-Status Information Element with the correct value within the ASSIGNMENT 
COMPLETE message. 

4.3.2 Optional Intra-Network Call Detection 

4.3.2.1 General 

As an option during call establishment, the tMSC server or the tBSS may utilise the Network ID within the Global Call 
Reference in order to determine whether the call is an intra-network call (e.g. compare the Network ID within the GCR 
with the Network ID of the tMSC server). 

4.3.2.2 Intra-Network Call Detection within the tMSC server 

The terminating MSC-Server may perform an intra-network call detection as follows: 

- if the Network ID in the GCR is the same as the Network ID of the terminating MSC-Server it means that the 
call is an intra-network call and the terminating MSC-Server shall proceed as for the case if no Intra-Network 
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Call Detection is performed i.e. including the GCR and LCLS -Configuration Information Elements, but not 
including the LCLS -Correlation-Not-Needed Information Element, within the ASSIGNMENT REQUEST 
message. 

if the Network ID in the GCR is different from the Network ID of the terminating MSC-Server it means that the 
call is not an intra-network call and the terminating MSC-Server shall include GCR, LCLS -Configuration, and 
LCLS-Correlation-Not-Needed Information Elements within the ASSIGNMENT REQUEST message. 

NOTE: Intra-Network call detection within the tMSC server can minimize the processing in some BSS 
implementations. 

4.3.2.3 Intra-Network Call Detection within the tBSS 

When receiving a GCR Information Element the tBSS may perform intra-network call detection as follows: 

if the Network ID in the GCR is the same as the Network ID of the terminating BSS it means that the call is an 
intra-network call and the terminating BSS shall perform call leg correlation. 

if the Network ID in the GCR is different from the Network ID of the terminating BSS it means that the call is 
not an intra-network call and the terminating BSS shall only store the GCR for the assigned call leg and does not 
need to perform call leg correlation. 

The tBSS shall indicate the resulting outcome to the tMSC server in the LCLS -BSS -Status Information Element within 
the Assignment Complete. 



4.3.3 Optional Intra-BSS Call Detection 



4.3.3.1 General 

As an option during call establishment, the tMSC server or tBSS may utilize the oBSS Node ID within the Call 
Reference ID of the GCR, in order to determine whether the call is an intra-BSS call (e.g. compare the oBSS Node ID 
with the tBSS Node ID) as described below. 

NOTE: After the oMSC server has generated the GCR IE, an Inter-BSS handover may occur at the originating 
side, therefore the encapsulated BSS ID is no longer the same as the BSS ID of the new Target BSS (see 
also sub-clause 8.4.1.1). Due to that, the result of the "BSS ID Pre-Check" procedure may be incorrect 
leading to "LCLS-Correlation-Not-Needed" indication being sent to the tBSS whilst the new target BSS 
could in fact be the same as the tBSS. If the tBSS does not perform the correlation of the GCR then the 
information in the Assignment Complete message may also be inaccurate (the LCLS-BSS-Status IE may 
indicate "call not possible to be locally switched" instead of "call not yet locally switched"). If the tMSC 
server indicates "LCLS-Correlation-Not-Needed" and the Inter-BSS handover has occurred at the oUE 
into the same BSS as the tUE but after signalHng the GCR IE and the tBSS does perform full GCR 
correlation then the LCLS-BSS-Status will indicate accurately that the call can be locally switched. 

4.3.3.2 Intra-BSS Call Detection within the tMSC server 

The terminating MSC-Server performs intra-BSS call detection as follows: 

- if the oBSS Node ID in the GCR is the same as the terminating BSS Node ID, the terminating MSC-Server shall 
proceed as for the case when no Intra-BSS Call Detection is performed i.e. including the GCR and LCLS- 
Configuration Information Elements, but not including the LCLS-Correlation-Not-Needed Information Element, 
in the ASSIGNMENT REQUEST message (if LCLS is otherwise allowed from CN point of view). 

- if the oBSS Node ID in the GCR is different from the terminating BSS Node ID, the terminating MSC-Server 
shall include the GCR, LCLS -Configuration, and LCLS-Correlation-Not-Needed Information Elements within 
the ASSIGNMENT REQUEST message. 

NOTE: Intra-BSS call detection within the tMSC server can minimize the processing in some BSS 
implementations. 
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4.3.3.3 Intra-BSS Call Detection within the tBSS 

When receiving a GCR Information Element the tBSS may perform intra-BSS call detection as follows: 

- if the oBSS Node ID in the GCR is the same as the BSS Node ID of the terminating BSS the terminating BSS 
shall perform call leg correlation. 

- if the oBSS Node ID in the GCR is different from the BSS Node ID of the terminating BSS the terminating BSS 
shall only store the GCR for the assigned call leg and does not perform call leg correlation. 

The tBSS shall indicate the resulting outcome to the tMSC server in the LCLS -BSS -Status Information Element within 
the ASSIGNMENT COMPLETE message. 

4.4 LCLS Connection Control 

LCLS connection control enables the Core Network to indicate to the BSS when the call is requested to be locally 
switched within the BSS or not. LCLS connection control is explicitly signalled on the A interface during Call 
Establishment, Handover and LCLS Break/(Re)Establishment using the LCLS_CONNECT_CONTROL message. 

Within the LCLS_CONNECT_CONTROL message, the LCLS -Connection-Status-Control Information Element shall 
indicate whether the BSS is requested to: 

- establish local switching (connect) 

- do not establish local switching (this value is used for example in call hold to explicitly prevent LCLS 
connection) 

- bi-cast at handover (this is a temporary status for the other call leg which is not being handed over. After 
handover has been completed and LCLS is broken, the BSS shall adopt the previous LCLS -Connection-Status- 
Control value i.e. "connect" unless explicitly changed by the MSC Server. This means that any subsequent 
handover of the previous call leg back into the same BSS will enable LCLS without any change of LCLS - 
Connection-Status to this call leg) 

- release LCLS for the locally switched call (Release LCLS) 

LCLS through-connection is established when the BSS receives, on both call legs, the LCLS -Connection-Status-Control 
IE to allow and request LCLS to be established. 

The detailed call flows and procedures for signalling of the LCLS-Connection-Status-Control IE during Call 
Establishment, LCLS Break/(Re)Establishment, and Handover are defined in clauses 6, 7, and 8 respectively. 

The LCLS_CONNECT_CONTROL message and the usage of the LCLS-Connection-Status-Control IE are further 
detailed in sub-clause 16.3. 

4.5 LCLS Status Reporting 

4.5.1 LCLS BSS Status between BSS and Core Network 

LCLS BSS status is required between the BSS and the Core Network in order to keep the originating MSC server and 
the terminating MSC server updated of the LCLS status in the respective BSS. 

The LCLS -BSS -Status Information Element is used to indicate whether: 

- the call is locally switched with requested LCLS configuration 

- the call is local but not yet locally switched (this indicates that the call has been correlated but not locally 
switched) 

- the call is not possible to be locally switched (this indicates that the call has been determined not to be a local 
call) 

- the call is no longer locally switched 
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- the requested LCLS -Configuration is not supported 

The inclusion of the LCLS-BSS-Status Information Element in responses to the MSC server indicates support of LCLS 
feature by the BSS. The usage of the LCLS-BSS-Status Information Element is further detailed in sub-clause 16.3. 

The LCLS-BSS-Status IE is explicitly signalled on the A interface during Call Establishment, LCLS 
Break/(Re)Establish LCLS, and Handover procedures. See clauses 6, 7 and 8 respectively. 

The LCLS-BSS-Status IE is also signalled expHcitly in the LCLS_NOTIFICATION message on the A interface, 
triggered by the BSS to notify the core network of any LCLS status changes in the BSS, e.g. BSS Initiated LCLS Break. 
The LCLS_NOTIFICATION message is further detailed in sub-clause 16.3. 

4.5.2 LCLS Status within the Core Network 

LCLS status is required within the Core network in order to update all of the (G)MSC server and intermediate nodes in 
the call control path of the LCLS status of the call. 

LCLS -Status Information Element is explicitly signalled on the Nc interface during Call Establishment, LCLS 
Break/(Re)Establish, and Handover procedures when the LCLS status changes from before and after handover. See 
clauses 6, 7, and 8 respectively. The LCLS-Status is either indicated as changed status (LCLS-Status IE) to a change in 
the BSS or it may be indicated as request to change the LCLS-Status (LCLS-Status-Change IE) due to handover or 
supplementary service invocation for example. 

The LCLS-Status IE can indicate the following statuses: 

- the call is LCLS connected 

- the call is not LCLS connected 

- the call is LCLS feasible but not yet connected 

The LCLS-Status-Change IE can indicate the following statuses: 

- LCLS is to be released 

- LCLS is to be released due to handover 

- LCLS is to be re-connected after LCLS break 

The MSC Servers shall only generate or forward the LCLS Status IE through the CN if there is a change to the current 
CN status (i.e. there is not a one to one mapping of the LCLS-BSS Status and the LCLS Status in the CN). The usage of 
these elements: the LCLS Status IE signalled in the LCLS_STATUS_UPDATE message and the LCLS-Status-Change 
IE which is signalled in the LCLS_STATUS_CHANGE_REQUEST message and 
LCLS_STATUS_CHANGE_REQUEST ACKNOWLEDGEMENT message is further detailed in sub-clause 16.1. 

4.6 User Plane when LCLS is Active 
4.6.1 General 

When LCLS has been established for a call, the voice data on the user plane is locally switched within the BSS. When 
the call is locally switched the core network shall assume that no user plane data will be received from the BSS for the 
duration of the locally switched call unless explicitly requested via the LCLS -Configuration IE. 

When user plane data is required to be inserted by the core network, e.g. supplementary services, unless previously 
negotiated via the LCLS -Negotiation IE (see sub-clause 4.2) an LCLS Break procedure shall precede the insertion of 
user plane data. 

NOTE: During Handover procedures and LCLS Break procedures, the BSS may start to send the user plane data 
to the core network before all nodes in the routing path have updated their related LCLS status, see 
clauses 7 and 8. 
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4.6.2 LCLS Configuration 



LCLS configuration is required in order to allow the Core Network to indicate to the BSS the LCLS connection 
preference. 

The LCLS Configuration Information Element is explicitly signalled on the A interface on a per call leg basis during 
Call Establishment and Handover procedures or at any time during the call using the LCLS_CONNECT_CONTROL 
message. See clauses 6 and 8 respectively. It is used to indicate if the local call shall be: 

- connected both- way in the BSS (basic LCLS connection) 

- connected both- way in the BSS and bi-casted UL to the Core Network 

- connected both- way in the BSS and send access DL from the Core Network (BSS may combine or replace local 
DL data with DL data from the Core Network) 

connected both- way in the BSS and send access DL from the Core Network, block local DL 

- connected both- way in the BSS and bi-casted UL to the Core Network and send access DL from the Core 
Network (BSS may combine or replace local DL data with DL data from the Core Network) 

- connected both- way in the BSS and bi-casted UL to the Core Network and send access DL from the Core 
Network, block local DL (BSS shall block local DL data but continue send UL data locally) 

If the BSS does not support a certain configuration this shall be indicated with the LCLS-BSS-Status IE set to 
"requested LCLS configuration is not supported" to the MSC Server. 

NOTE: If BSS supports LCLS feature, then at least one of the LCLS configurations is required to be supported. 

The usage of the LCLS Configuration IE is further detailed in sub-clause 16.3. 



5 General Circuit Switched Core Network Domain 

Architecture 

LCLS does not require any modifications to the basic reference architecture. The General CS core network domain 
architecture is specified in 3GPP TS 23.205 [2]. Network Architecture for CS Core Network Nodes and GSM/EDGE 
Radio Access Networks is specified in 3GPP TS 23.002 [8]. 

NOTE: LCLS does introduce a number of conceptual changes as described in sub-clause 4.1. 



6 Call Establishment 

6.1 Basic Mobile Originating Call 

6.1 .1 Basic Mobile Originating Call with BICC based CS core network 

6.1.1.1 General 

The basic mobile originating call shall be established in accordance with 3GPP TS 23.205 [2]. The LCLS establishment 
may use forward or backward bearer establishment. The following sub-clauses describe the additional requirements 
related to the LCLS functionality. 

6.1.1.2 Initial Addressing 

If the oMSC server supports the LCLS feature it shall generate a Global Call Reference (GCR) IE. The GCR IE is 
derived from the ITU-T Global Call Reference IE [5] and specified in detail in the clause 16 and in 3GPP TS 29.205 
[6]. If the serving radio access is GERAN the Call Reference ID field of the GCR IE contains the originating BSS ID. 
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The oMSC server shall then include the GCR IE, LCLS -Negotiation Request IE and LCLS -Configuration-Preference IE 
indicating the preferences for LCLS as defined in the sub-clause 4.2, clause 16 and in 3GPP TS 29.205 [6], together 
with the Supported Codecs List IE for OoBTC as specified in 3GPP TS 23.153 [4] in the lAM message to the 
succeeding call control node. 

6.1.1.3 Access Bearer Assignment 

6.1 .1 .3.1 Assignment performed after LCLS Negotiation through Core Network 

On receipt of the APM from the succeeding MSC server containing the LCLS -Negotiation Response IE, indicating 
local call connection is permitted, the oMSC server shall continue with the basic call establishment and if the serving 
radio access is GERAN shall include the GCR IE and the LCLS -Configuration IE (which is derived from the LCLS- 
Configuration-Preference IE) in the originating BSSAP Assignment Request message (see 3GPP TS 48.008 [7]). 

If the serving radio access is UTRAN the oMSC server shall save the LCLS -Negotiation Response IE and LCLS- 
Configuration-Preference IE but proceed with the call establishment as described in TS 23.205 [2]. 

6.1 .1 .3.2 Assignment performed before LCLS Negotiation 

After generation of the GCR IE the oMSC initiates the access bearer assignment on the originating side and includes the 
GCR IE and the preliminary LCLS -Configuration IE (the final configuration can be different due to the following 
LCLS negotiation through the core network) in the originating BSSAP Assignment Request message. 

6.1.1.3.3 oBSS behavior 

If the originating BSS supports LCLS and receives the Assignment Request message containing the GCR IE and the 
LCLS -Configuration IE the originating BSS shall store the GCR IE against the Assigned Call leg and shall check if it 
can support the requested LCLS -Configuration. The originating BSS shall report the outcome in LCLS-BSS-Status IE 
returned to the MSC server in the Assignment Complete message. 

If the originating BSS does not support LCLS then the GCR IE and the LCLS -Configuration IE will be ignored and no 
LCLS-BSS-Status IE will be returned in the Assignment Complete message. The oMSC server shall continue the call 
establishment as for a Non-LCLS call. 

6.1 .1 .4 Backward LCLS Negotiation 

At reception of an APM, ACM or CPG message with the LCLS -Negotiation Response IE and the LCLS -Configuration- 
Preference IE the oMSC server shall check whether a new value of the LCLS -Configuration-Preference settings require 
the change of the requested LCLS configuration and if so the oMSC server shall include the updated LCLS- 
Configuration IE in the BSSAP message LCLS Connect Control to the BSS, see sub-clause 6.1.1.5. If the LCLS- 
Negotiation Response IE indicates "LCLS Not Allowed" or "LCLS not supported by subsequent node" then the oMSC 
Server shall not permit LCLS connection unless any subsequent LCLS negotiation results in LCLS being feasible. 

NOTE 1: The oMSC can still signal the GCR to the BSS in order to avoid a subsequent Assignment to pass the 
GCR if LCLS becomes feasible at a later time during the call. 

At reception of an unsolicited APM message without LCLS -Negotiation Response IE then the oMSC shall handle the 
APM but not change the LCLS -Configuration or any LCLS behaviour. 

NOTE 2: APM is used for other services or applications and need not include LCLS -Negotiation Response IE. 

If the first backward message (APM or ACM) does not contain the LCLS -Negotiation Response IE then the oMSC 
Server shall not proceed with further LCLS signalling for this call. 

NOTE 3: This indicates to the oMSC server that the LCLS feature is not supported by succeeding node. 

6.1 .1 .5 LCLS Through-Connection 

If the originating BSS determines that the call is local and can be locally switched it shall not through-connect the two 
parties unless explicitly indicated to do so by receiving the LCLS -Connection-Status-Control IE set to "Connect" for 
both call legs. 
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When the oMSC server receives the ANM from the succeeding MSC server with the LCLS-Status IE indicating "LCLS 
is feasible but not yet connected" it shall send the BSSAP message LCLS-Connect-Control to the originating BSS 
containing the LCLS -Connection-Status-Control IE set to "Connect". If the value of the required LCLS Configuration is 
not the same as the value requested within the Assignment Request message, the oMSC Server shall also include the 
LCLS Configuration IE in the LCLS-Connect-Control message. 

If the BSS has received the LCLS -Connection-Status-Control IE set to "Connect" for both call legs associated to the 
LCLS call it shall locally switch the user plane between the two call legs and report the through-connection via the 
LCLS -BSS -Status IE set to "the call is locally switched with requested LCLS configuration" in the LCLS-Connect- 
Control Acknowledge message. The CN user plane shall be kept through-connected as described in the sub-clause 4.6. 

If the call is not yet locally switched when returning the LCLS-Connect-Control Acknowledge message but becomes 
locally switched at a later time (for example due to the LCLS -Connection-Status-Control IE requesting "Connect" at the 
second call leg) the BSS shall report the change in status via the LCLS -BSS -Status IE set to "the call is locally switched 
with requested LCLS configuration" within the LCLS -Notification message as specified in 3GPP TS 48.008 [7]. 

NOTE: This should not occur at the oMSC server for normal call establishment as the oMSC server should 
always be the last (second) node sending the LCLS-Connect-Control message to the BSS. 

6.1 .1 .6 LCLS Status Reporting 

When the oMSC server receives the LCLS-Connect-Control Acknowledge message from the originating BSS with the 
LCLS -BSS -Status IE set to "the call is locally switched with requested LCLS configuration" it shall inform the 
succeeding MSC server with the APM message containing the LCLS Status IE set to "LCLS connected". 

During the LCLS call establishment and ongoing call any change to the LCLS connection status is reported by the BSS 
to the core network and only if it results in a change of the LCLS status in the core network, the updated LCLS status 
shall be signalled by the oMSC server to the succeeding nodes. See also sub-clause 4.5. 

6.1.1.7 MGW/User plane 

The MGW/user plane shall be established in accordance with 3GPP TS 23.205 [2]. 

6.1 .2 Basic Mobile Originating Call with SIP-I based CS core network 

6.1.2.1 General 

The basic mobile originating call shall be established in accordance with 3GPP TS 23.231 [3]. The LCLS principles 
introduced in the sub-clause 6. LI for BICC protocol messages should also apply to SIP-I signalling cases. 

6.1.2.2 Initial Addressing 

The oMSC server shall send the initial SIP-I INVITE request with the GCR IE, LCLS -Negotiation Request IE and 
LCLS -Configuration-Preference IE included within the encapsulated lAM message if the LCLS feature is supported. If 
an access bearer assignment has not been completed the initial SDP offer shall indicate that the local preconditions have 
not been met. 

6.1 .2.3 Access Bearer Assignment 

On receipt of the SIP-I 183 Session Progress provisional response from the succeeding MSC server containing the 
LCLS -Negotiation Response IE and LCLS -Configuration-Preference IE included within the encapsulated APM 
message, the oMSC server shall continue with the basic call establishment as specified in the sub-clause 6.1.L3. 

6.1 .2.4 Backward LCLS Negotiation 

At reception of the SIP-I 183 Session Progress provisional response with the LCLS -Negotiation Response IE and 
LCLS -Configuration-Preference IE included within the encapsulated APM message the oMSC server shall check the 
value of the LCLS -Negotiation Response IE and the LCLS -Configuration-Preference IE as specified in the sub-clause 
6.1.1.4. 
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If the first 183 Session Progress provisional response does not contain the LCLS Negotiation Response IE then the 
oMSC Server shall not proceed with further LCLS signalling for this call. 

NOTE: This indicates to the oMSC server that LCLS feature is not supported by succeeding node. 

6.1 .2.5 LCLS Through-Connection 

On the reception of the 200 OK final response to the initial INVITE with the encapsulated ANM message containing 
LCLS-Status IE the oMSC server shall apply the LCLS Through-Connection procedure specified in the sub-clause 
6.1.1.5. 

6.1 .2.6 LCLS Status Reporting 

The oMSC server shall send the SIP-I INFO request containing the LCLS Status IE included within the encapsulated 
APM message to the succeeding MSC server when LCLS Status Reporting needs to be performed according to 
procedure described in the sub-clause 6.1.1.6. 

6.1.2.7 MGW/User plane 

The MGW/user plane shall be established in accordance with 3GPP TS 23.205 [2]. 

6.2 Basic Mobile Terminating Call 

6.2.1 Basic Mobile Terminating Call with BICC based CS core network 

6.2.1.1 General 

The basic mobile terminating call shall be established in accordance with 3GPP TS 23.205 [2]. The LCLS establishment 
may use forward or backward bearer establishment. The following sub-clauses describe the additional requirements 
related to the LCLS functionality. 

6.2.1 .2 Actions at Intermediate Nodes (including GMSC) 

6.2.1.2.1 Initial Addressing 

If an intermediate node supports the LCLS feature and receives the LCLS -Negotiation Request IE and LCLS- 
Configuration-Preference IE from a preceding node in the I AM it may modify the LCLS -Configuration-Preference IE 
based on its own LCLS configuration requirements, and shall then forward the resulting LCLS -Configuration- 
Preference IE together with GCR IE and LCLS -Negotiation Request IE to the succeeding node. The rules for modifying 
the LCLS -Configuration-Preference IE are specified in the sub-clause 4.2. 

If LCLS is not permitted by the intermediate node based on its own LCLS requirements then it shall set the LCLS- 
Negotiation Request IE to value "LCLS not allowed". The intermediate node shall forward the LCLS -Negotiation 
Request IE, LCLS -Configuration-Preference IE and GCR IE to the succeeding node. 

6.2.1 .2.2 Backward LCLS Negotiation 

If the intermediate node supports the LCLS feature and has sent the GCR IE, the LCLS -Negotiation Request IE and 
LCLS -Configuration-Preference IE within I AM message towards the succeeding node further action depends on the 
content of the first received backward message (APM message or ACM). 

- If the intermediate node receives the first backward message (APM or ACM) without the LCLS -Negotiation 
Response IE it shall include the LCLS -Negotiation Response IE indicating "LCLS not supported by subsequent 
node into APM/ACM before forwarding the APM/ ACM to the preceding node. 
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NOTE 1 : This indicates to preceding nodes that the LCLS feature is not supported by the succeeding nodes 

except the intermediate node but that further LCLS negotiation can occur. Specifically this can arise 
due to subsequent call control signalling to other succeeding nodes, e.g. due to changed routing, 
handover or supplementary service interactions. If the intermediate node does not include any LCLS- 
Negotiation Result IE then it implicitly indicates to the preceding node that LCLS feature is not 
supported by the intermediate node and no further LCLS signalling is permitted for the call. 

- When the received APM/ACM contains the LCLS -Negotiation Response IE then the forwarding MSC server 
shall forward the received LCLS -Negotiation Response IE and LCLS -Configuration-Preference IE to the 
preceding node. 

If the intermediate node has forwarded LCLS -Negotiation Response IE in the first backward APM/ACM message and 
receives an APM which does not include LCLS Negotiation Response IE then the intermediate node shall handle the 
APM but shall not include any LCLS IE when passing on such APM's; no changes to LCLS status shall result. 

NOTE 2: APM is used for other services or applications and need not include LCLS lEs. 

Other information elements shall be treated as specified in 3GPP TS 23.205 [2] and in 3GPP TS 23.231 [3]. 

6.2.1 .2.3 Through-Connection 

The procedure specified in 3GPP TS 23.205 [2] shall be applied. 

6.2.1 .2.4 LCLS Status Reporting within CN 

If the LCLS status is received from its adjacent node, the MSC server shall update the LCLS status and shall pass on to 
the next node only if the LCLS status has changed. See also sub-clause 4.5. 

6.2.1.2.5 MGW/User plane 

The MGW/user plane shall be estabHshed in accordance with 3GPP TS 23.205 [2]. 

6.2.1 .3 Actions at Ternninating Gall side 

6.2.1.3.1 Initial Addressing 

If the tMSC server supports LCLS feature and receives the GCR IE, the LCLS -Negotiation Request IE and the LCLS- 
Configuration-Preference IE it may modify the LCLS -Configuration-Preference IE based on its own LCLS 
configuration requirements. The rules for modifying the LCLS -Configuration-Preference IE are specified in the clause 
4.2 and in 3GPP TS 29.205 [6]. 

6.2.1 .3.2 Backward LCLS Negotiation 

If the tMSC server supports LCLS feature then it shall return the LCLS -Negotiation Response IE and the LCLS- 
Configuration-Preference IE to the preceding node in the APM or the ACM message. 

6.2.1 .3.3 Access Bearer Assignment 

If the serving radio access is GERAN then when the tMSC server performs the access bearer assignment it shall include 
the GCR IE and the LCLS -Configuration IE (which is derived from the LCLS -Configuration-Preference IE) in the 
BSSAP Assignment Request message sent to the terminating BSS (see 3GPP TS 48.008 [7]). 

If the tMSC server supports the optional "intra-Network call detection" procedure and determines that the Network ID 
within the GCR IE is not equal to the own (tMSC) Network ID, the tMSC server shall also include the "LCLS- 
Correlation-Not-Needed" IE in the Assignment Request message (see sub-clause 4.3.2). 

If the tMSC server supports the optional "intra-BSS call detection" procedure and determines that the BSS ID within the 
GCR IE is not equal to the terminating BSS ID, the tMSC server shall also include the "LCLS -Correlation-Not-Needed" 
IE in the Assignment Request message (see sub-clause 4.3.3). 

If the terminating BSS supports LCLS and receives the Assignment Request message containing the GCR IE and the 
LCLS -Configuration IE, the BSS shall store the GCR against the Assigned Call leg and check if it can support the 
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requested LCLS -Configuration. Unless the BSS supports the optional "intra-Network call detection" procedure (see 
sub-clause 4.3.2) or optional "intra-BSS call detection" procedure (see sub-clause 4.3.3) it shall perform a correlation of 
the received GCR to see if another call leg has been assigned with the same GCR and report the outcome in the LCLS- 
BSS-Status IE returned to the tMSC server in the Assignment Complete message. 

If the terminating BSS does not support LCLS then the GCR IE and the LCLS -Configuration IE will be ignored and no 
LCLS -BSS -Status IE will be returned in the Assignment Complete message. The tMSC server shall continue the call 
establishment as for normal Non-LCLS call. 

6.2.1 .3.4 LCLS Through-Connection 

If the terminating BSS determines that the call is local and can be locally switched it shall not through-connect the two 
parties unless explicitly indicated to do so by receiving the LCLS -Connection-Status-Control IE set to "Connect" for 
both call legs. 

When the tMSC server receives "answer" from the terminating UE it shall send the BSSAP message LCLS-Connect- 
Control containing the LCLS-Connection-Status-Control IE set to "Connect" and send the ANM message with the 
LCLS-Status IE indicating "LCLS is feasible but not yet connected" to the preceding MSC server. 

If the BSS has received the LCLS -Connection-Status-Control IE set to "Connect" for both call legs associated to the 
LCLS call it shall locally switch the user plane between the two call legs and report the through-connection via LCLS- 
BSS-Status IE set to "the call is locally switched with requested LCLS configuration" in the LCLS-Connect-Control 
Acknowledge message. The CN user plane shall be kept through-connected as described in the sub-clause 4.6. 

If the call is not yet locally switched when returning the LCLS-Connect-Control Acknowledge message but becomes 
locally switched at a later time (for example due to the LCLS -Connection-Status-Control IE requesting "Connect" at the 
second call leg) the BSS shall report the change in status via LCLS -BSS -Status IE set to "the call is locally switched 
with requested LCLS configuration" within the LCLS -Notification message as specified in 3GPP TS 48.008 [7]. 

6.2.1 .3.5 LCLS Status Reporting 

During the LCLS call establishment and ongoing call any change to the LCLS connection status is reported by the BSS 
to the core network and only if it results in a change of the LCLS status in the core network the updated LCLS status 
shall be signalled by the tMSC server to the preceding node. See also sub-clause 4.5. 

6.2.1.3.6 MGW/User plane 

The MGW/user plane shall be estabhshed in accordance with 3GPP TS 23.205 [2]. 

6.2.2 Basic Mobile Terminating Call with SIP-I based CS core network 

6.2.2.1 General 

The basic mobile terminating call shall be established in accordance with 3GPP TS 23.231 [3]. The LCLS principles 
using introduced in the sub-clause 6.2.1 for BICC protocol messages should also apply to SIP-I signalling cases. 

6.2.2.2 Actions at Internnediate Nodes (including GMSC) 
6.2.2.2.1 Initial Addressing 

If an intermediate node supports the LCLS feature and receives the GCR IE, the LCLS -Negotiation Request IE and the 
LCLS -Configuration-Preference IE included within the encapsulated I AM message from a preceding node in the SIP-I 
INVITE request it may modify the LCLS -Configuration-Preference IE based on its own LCLS configuration 
requirements, and shall then forward the initial INVITE request with the resulting LCLS -Configuration-Preference IE 
together with GCR IE and LCLS -Negotiation Request IE included within the encapsulated I AM message to the 
succeeding node. 
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6.2.2.2.2 Backward LCLS Negotiation 

On the receipt of the 183 Session Progress provisional response the intermediate node shall apply the Backward LCLS 
Negotiation procedure specified in the sub-clause 6.2.1.2.2. 

6.2.2.2.3 Through-Connection 

See sub-clause 6.2.1.2.3. 

6.2.2.2.4 LCLS Status Reporting within CN 

See sub-clause 6.2.1.2.4. 

6.2.2.2.5 MGW/User plane 

See sub-clause 6.2.1.2.5. 

6.2.2.3 Actions at Ternninating Gall side 

6.2.2.3.1 Initial Addressing 

See sub-clause 6.2.1.3.1. 

6.2.2.3.2 Backward LCLS Negotiation 

If the tMSC server supports LCLS feature then it shall return the final LCLS -Negotiation Response IE and LCLS- 
Configuration-Preference IE included within the encapsulated APM message to the preceding node in the SIP-I 183 
Session Progress provisional response. 

6.2.2.3.3 Access Bearer Assignment 

See sub-clause 6.2.1.3.3. 

6.2.2.3.4 LCLS Through-Connection 

The tMSC server shall apply the LCLS Through-Connection procedure specified in the sub-clause 6.2.1.3.4. The 
LCLS -Status IE indicating "LCLS is feasible but not yet connected" shall be included in the ANM message 
encapsulated in the 200 OK final response to the initial INVITE. 

6.2.2.3.5 LCLS Status Reporting 

See sub-clause 6.2.1.3.5. 

6.2.2.3.6 MGW/User plane 

See sub-clause 6.2.1.3.6. 

6.3 Basic Mobile to Mobile End to End Call Examples 
6.3.1 Basic Call Establishment Connection Model for LCLS 

Figure 6.3.1.1 shows the network model for the basic call establishment for a Local Call. The oMSC server seizes one 
context with two bearer terminations in the oMGW. The bearer termination Tl is used for the bearer towards the oBSS 
and the bearer termination T2 is used for the bearer towards the iMSC selected iMGW. The iMSC server seizes one 
context with two bearer terminations in the iMGW. The bearer termination T6 is used for the bearer towards the tMSC 
server selected tMGW and the bearer termination T5 is used for the bearer towards the preceding oMGW. The tMSC 
server seizes one context with two bearer terminations in the tMGW. The bearer termination T3 is used for the bearer 
towards the iMSC selected iMGW and bearer termination T4 is used for the bearer towards the tBSS. 
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6.3.2 



Connection Model 2: After answer, Call is locally switched 
Figure 6.3.1.1: Basic Call Establishment Connection Model for Local Call 

LCLS established, Basic Call Example with BICC based CS core 
network, forward bearer establishment 



Figures 6.3.2.1, 6.3.2.2 and 6.3.2.3 show the message sequence example for the basic call establishment for LCLS. In 
this example the oUE and the tUE belong to the same BSS (marked as oBSS and tBSS) and the CN permits LCLS. The 
example is based on examples from 3GPP TS 23.205 [2] for the basic mobile originating call, forward bearer 
establishment (case when access bearer assignment is requested on the originating side after reception of Bearer 
Information message) and the basic mobile terminating call, forward bearer establishment. 
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Figure 6.3.2.1 : Basic Call Establishment Flow when call is locally switched, forward bearer 

establishment 

Service Request handling. 

Originating Call SETUP. 

The oMSC server replies with the CALL PROCEEDING message to indicate that the call is being processed. 

If the oMSC server supports LCLS it retrieves the oBSS ID and generates the Global Call Reference for the 
call. 

The oMSC server sends the I AM message including supported codecs list, GCR with encapsulated oBSS ID, 
and configures the LCLS-Negotiation IE. 

If the iMSC server supports LCLS it may modify the LCLS-Negotiation IE due to CAMEL, supplementary 
service requirements etc. before sending the lAM message containing the GCR with the encapsulated oBSS 
ID and the LCLS-Negotiation IE. 

The tMSC server pages the tUE. 

The tMSC server performs call Setup. 

The tUE confirms the call. 

The tMSC server requests the tMGW to prepare for the network side bearer establishment. 
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10. After the tMGW has repHed with the bearer address and the binding reference the tMSC server returns the 
APM message with the selected codec, available codec list and if LCLS is supported, the LCLS -Negotiation 
IE. 

11a. When the bearer information is received the iMSC server requests the seizure of the outgoing network side 
bearer termination. 

1 lb. After the outgoing side bearer termination is seized the iMSC server requests the seizure of the incoming 
network side bearer termination. 

During the seizure of the outgoing side and the incoming side bearer termination the iMSC server will also 
request the iMGW to through-connect the bearer terminations so that the bearer will be both way through- 
connected. 

12. The iMSC server transfers the APM message with the selected codec, available codec list and the LCLS- 
Negotiation IE. 

13a. When the bearer information is received the oMSC server requests the seizure of the network side bearer 
termination. 

13b. After the network side bearer information is seized the oMSC server requests the seizure of the access side 
bearer termination. 

During the seizure of the network side or the access side bearer termination the oMSC server will also 
request the oMGW to through-connect the bearer terminations so that the bearer will be backward through- 
connected. 
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Figure 6.3.2.2: Basic Call Establishment when call is locally switched, forward bearer establishment 

(continuation of figure 6.3.2.1) 
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14. The oMSC server determines whether LCLS is allowed in the core network based on the returned LCLS- 
Negotiation IE and if so the oMSC server includes the LCLS -Configuration IE in the ASSIGNMENT 
REQUEST message along with the GCR IE. 

15. The oBSS returns the ASSIGNMENT COMPLETE message with the LCLS -BSS -Status IE indicating "call 
not possible to be locally switched". 

16. When the access assignment is completed the oMSC server sends the Continuity (COT) message to the 
iMSC server. 

17. The iMSC server transfers the COT message to the tMSC server. 

18. The tMSC server requests the seizure of the access side bearer termination. If not requested during the 
seizure of network side bearer termination (step 9b) the tMSC server will request the tMGW to through- 
connect the bearer terminations so that the bearer will be backward through-connected. 

19a. If the tMSC server supports the optional "intra-Network call detection" procedure it compares its own 
Network ID with the Network ID received within the Global Call Reference IE. 

If the tMSC server supports the optional "intra-BSS call detection" procedure it compares the BSS ID of the 
selected terminating BSS with the oBSS ID received within the Global Call Reference IE at this step. Since 
the oUE and the tUE belong to the same BSS the call continues the same way as for the basic LCLS 
establishment without this pre-check. 

19b. The tMSC server performs the access bearer assignment and sends the ASSIGNMENT REQUEST message 
containing the GCR IE and the LCLS -Configuration IE if LCLS is permitted in the core network. 

20. The oBSS/tBSS performs the GCR correlation. Since the GCR correlation has identified the call as an intra 
BSS call and LCLS is allowed in the BSS, the tBSS returns the ASSIGMENT COMPLETE message with the 
LCLS -BSS -Status IE indicating "Call not yet locally switched". 

20a. Since the GCR correlation has identified the call as an intra BSS call and LCLS is allowed in the BSS, the 

oBSS signals the LCLS status change by sending the LCLS_NOTIFICATION message with the LCLS-BSS- 
Status IE set to "Call not yet locally switched". 

2 1 . The tUE reports alerting. 

22a, b. The tMSC server returns the ACM message and requests the tMGW to provide a ring-back tone. 

23. The iMSC server transfers the ACM message to the oMSC server. 

24. The oMSC server reports alerting. 
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Figure 6.3.2.3: Basic Call Establishment when call is locally switched, forward bearer establishment 

(continuation of figure 6.3.2.2) 

25. The tUE answers the call. 

25a. The tMSC server returns the CONNECT ACKNOWLEDGE message to the tUE. 

26. The tMSC server indicates to the tBSS that this call leg is ready to be locally switched by sending the 
LCLS_CONNECT_CONTROL message (note the BSS cannot through-connect LCLS until it receives the 
same indication from the oMSC server). 

27. The tBSS returns the LCLS_CONNECT_CONTROL_ACK message with the LCLS-BSS-Status IE set to 
"Call not yet locally switched" since the BSS has not received the same order from the oMSC server. 

28. When the tMSC server receives the Connect message it requests the tMGW to stop providing ring-back tone 
to the calling party and requests to bothway through-connect the bearer. 

29. The tMSC server returns the ANM message with the LCLS-Status IE indicating "LCLS is feasible but not yet 
connected" . 

30. The oMSC server receives the ANM message with the LCLS-Status IE indicating "LCLS is feasible but not 
yet connected" . 
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3 1 . The oMSC server request the oMGW to both way through-connect the bearer. 

32. The oMSC server reports Answer/Connect to the oUE. 

32a. The oUE completes the call establishment with the CONNECT ACKNOWLEDGE message. 

33. The oMSC server requests the oBSS to connect LCLS since the received ANM message indicated "LCLS is 
feasible but not yet connected". 

34a. Since the BSS has received the through connect request for both call legs the oBSS returns the 

LCLS_CONNECT_CONTROL_ACK message with the LCLS -BSS -Status IE set to "call is locally switched 
with requested LCLS configuration" . 

NOTE 1 : If the BSS cannot locally through-connect the call at this time then it is indicated by setting the 
LCLS -BSS -Status IE set to "the call is not yet locally switched". If at a later time the BSS can 
locally switch the call, this is indicated by sending the LCLS_NOTIFICATION message with the 
LCLS -BSS -Status IE set to "the call is locally switched with requested LCLS configuration". 

34b. Since the BSS has received the through connect request for both call legs the tBSS signals the LCLS status 
change by sending the LCLS_NOTIFICATION message with the LCLS -BSS -Status IE set to "call is locally 
switched with requested LCLS configuration" . 

34c. If the oMSC server supports the option to configure its Access MGW to isolate the access side termination 
from the network side termination and LCLS negotiation indicated that no succeeding node requires the UL 
data from the oUE then the oMSC server requests the oMGW to isolate the access side termination Tl from 
the network side termination T2. 

34d. If the tMSC server supports the option to configure its Access MGW to isolate the access side termination 
from the network side termination and LCLS negotiation indicated that no preceding node requires the UL 
data from the tUE then the tMSC server requests the tMGW to isolate the access side termination T4 from 
the network side termination T3. 

NOTE 2: The MSC server can also use the Change Through-Connection procedure and requests the MGW 
to change the through-connection of the bearer to inactive instead of using of the Isolate Bearer 
termination procedure, see 3GPP TS 23.205 [2]. 

35. The oMSC server signals the change of the LCLS status through the Core Network by sending the APM 
message with the LCLS-Status IE set to "LCLS connected". 

36. The iMSC server transfers the change of the LCLS status to the tMSC server. 

6.3.3 LCLS not established, Basic Call Example with BICC based CS core 
network 

The Figure 6.3.3.1 shows the message sequence example for the basic call establishment for LCLS when the call could 
not be locally switched. In this example the CN permits LCLS but the oUE and the tUE belong to different BSS's 
(marked as oBSS and tBSS). The example is based on examples from 3GPP TS 23.205 [2] for the basic mobile 
originating call, forward bearer establishment and the basic mobile terminating call, forward bearer establishment. 
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Figure 6.3.3.1 : Basic Call Establishment Flow when call is not locally switched 

1-18. The basic call establishment procedure between the UE-1 and the UE-2 is the same as specified in steps 1-18 
of sub-clause 6.3.2.1. 

19a. If the tMSC server supports the optional "Intra-Network Call Detection" procedure it may compare its own 
Network ID with the Network ID received within the Global Call Reference (GCR) IE. 
If the tMSC server supports the optional "Intra-BSS Call Detection" procedure it may compare the BSS ID of 
the selected terminating BSS with the value of the originating BSS ID received within the GCR IE at this 
step. 

In this case, the result of the "Intra-Network Call Detection" procedure or "Intra-BSS Call Detection" 
procedure is that the call is not an intra-Network or an intra-BSS call. 

19b. The tMSC server performs the terminating access bearer assignment and sends the ASSIGNMENT 

REQUEST message containing the GCR IE and the LCLS-Configuration IE if LCLS is permitted in the core 

network. 

If the tMSC server performed the "Intra-Network Call Detection" procedure in step 19a and/or the tMSC 

server performed the "Intra-BSS Call Detection" procedure in step 19a, then the tMSC server includes the 

"LCLS-Correlation-Not-Needed" IE in the ASSIGNMENT REQUEST message since the oUE and the tUE 

belong to the different BSS's. 

20. The tBSS returns the ASSIGMENT COMPLETE message with the LCLS -BSS -Status IE indicating "Call 
Not Possible to be Locally Switched". 
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21 - 30.The basic call establishment procedure between the UE-1 and the UE-2 continues as for the normal, non- 
LCLS call. 



6.3.4 LCLS established, Basic Call Example with SIP-I based CS core 
network 

Figures 6.3.4.1, 6.3.4.2, 6.3.4.3 and 6.3.4.4 show the message sequence example for the basic call establishment when 
call is locally switched. In this example the oUE and the tUE belong to the same BSS (marked as oBSS and tBSS) and 
the CN permits LCLS. The example is based on examples for the basic mobile originating call and for the basic mobile 
terminating call from 3GPP TS 23.231 [3]. 
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Figure 6.3.4.1 : Basic Call Establishment Flow when call is locally switched 

Service Request handling. 

Originating Call SETUP. 

The oMSC server replies with a CALL PROCEEDING message to indicate that the call is being processed. 

If the oMSC server supports LCLS it retrieves the oBSS ID and generates the Global Call Reference for the 
call. 

The oMSC server selects the codec and requests the oMGW to select and provide the IP transport address 
and port for the network side bearer connection before sending the INVITE message. 
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6. The oMSC server sends the INVITE request with the initial SDP offer indicating that local preconditions 
have not been met, and with the encapsulated lAM message containing the GCR with encapsulated oBSS ID, 
and the LCLS -Negotiation IE. 

7. The iMSC server confirms the reception of the INVITE request with a 100 Trying provisional response. 

8. The iMSC server selects the codec and requests the iMGW to select and provide the IP transport address and 
port for the outgoing network side bearer termination. 

9. If the iMSC server supports LCLS it may modify the LCLS -Negotiation IE due to CAMEL, supplementary 
service requirements etc. before sending the INVITE request with the SDP offer and with the encapsulated 
lAM message containing the GCR with the encapsulated oBSS ID and the LCLS -Negotiation IE. 

10. The tMSC server confirms the reception of the INVITE request with 100 a Trying provisional response. 

1 1 . The tMSC server pages the tUE. 

12. The tMSC server performs call Setup. 

13. The tUE confirms the call. 

14. The tMSC server selects the codec, provides to the tMGW the selected codec and the remote user plane IP 
address and port information that were received from the preceding node in the SDP offer and requests the 
tMGW to prepare for the network side bearer establishment. 

15. After the tMGW has replied with the local IP address and port information the tMSC server includes in the 
SDP answer the user plane IP address and UDP port received from the tMGW, the selected codec and any 
additional accepted payload types. The tMSC server returns a 183 Session Progress provisional response with 
the SDP answer and if LCLS is supported with encapsulated APM message containing the LCLS -Negotiation 
IE. 

16. The iMSC server replies to succeeding node with the PRACK request to confirm the reception of the 183 
Session Progress provisional response. 

17. When the 183 Session Progress provisional response with the SDP answer is received the iMSC server 
requests the iMGW to configure the remote IP transport address and any additional negotiated payload types 
of the outgoing side bearer termination. 

18. The tMSC server confirms the reception of the PRACK request with a 200 OK final response. 
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Figure 6.3.4.2: Basic Call Establishment when call is locally switched (continuation of figure 6.3.4.1) 

19. The iMSC server selects the codec for the incoming side bearer termination, provides to the iMGW the 
selected codec and the remote user plane IP address and port information that were received from the 
preceding node in the SDP offer and requests the iMGW to prepare for the incoming side bearer 
establishment. 

During the seizure of the outgoing side and the incoming side bearer termination the iMSC server will also 
request the iMGW to through-connect the bearer terminations so that the bearer will be bothway through- 
connected. 

20. After the iMGW has replied with the local IP address and port information the iMSC server includes in the 
SDP answer the user plane IP address and UDP port received from the iMGW, the selected codec and any 
additional accepted payload types. The iMSC server sends the 183 Session Progress provisional response 
with the SDP answer and with encapsulated APM message containing the LCLS -Negotiation IE to the 
preceding node. 

21. The oMSC server replies to the succeeding node with the PRACK request to confirm the reception of the 183 
Session Progress provisional response. 

22. The oMSC server requests the oMGW to configure the remote user plane IP address and any additional 
negotiated payload types of the network side bearer termination. 

23. The oMSC server requests the seizure of the access side bearer termination. 

During the seizure of the network side or the access side bearer termination the oMSC server will also 
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request the oMGW to through-connect the bearer terminations so that the bearer will be backward through- 
connected. 

24. The iMSC server confirms the reception of the PRACK request with the 200 OK final response. 

25. The oMSC server determines whether LCLS is allowed in the core network based on the returned LCLS- 
Negotiation IE and if so the oMSC server includes the LCLS -Configuration IE in the ASSIGNMENT 
REQUEST message along with the GCR IE. 

26. The oBSS returns the ASSIGNMENT COMPLETE message with the LCLS -BSS -Status IE indicating "call 
not possible to be locally switched". 

27. When the oMSC server receives the ASSIGNMENT COMPLETE message, it requests the oMGW to 
configure the remote user plane IP address and UDP Port for the access side bearer termination. 

28. Since the access bearer assignment is completed the oMSC server sends the UPDATE request with the SDP 
offer indicating local preconditions met to the succeeding node. 

29. The iMSC server forwards the UPDATE request to the succeeding node. 

30. The tMSC server confirms the reception of the UPDATE request with the 200 OK final response. 

31. When the tMSC server receives the SDP offer indicating remote preconditions met it requests the seizure of 
the access side bearer termination. 

If not requested during the seizure of network side bearer termination (step 14) the tMSC server will request 
the tMGW to through-connect the bearer terminations so that the bearer will be backward through-connected. 

32. The iMSC server forwards the 200 OK (UPDATE) final response to the preceding node. 

33. If the tMSC server supports the optional "intra-Network call detection" procedure it compares its own 
Network ID with the Network ID received within the Global Call Reference IE. 

If the tMSC server supports the optional "intra-BSS call detection" procedure it compares the BSS ID of the 
selected terminating BSS with the oBSS ID received within the Global Call Reference IE at this step. Since 
the oUE and the tUE belong to the same BSS the call continues the same way as for the basic LCLS 
establishment without this pre-check. 
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34. The tMSC server sends the ASSIGNMENT REQUEST message containing the GCR IE and the LCLS- 
Configuration IE if LCLS is permitted in the core network. 

35. a) The tBSS performs the GCR correlation. Since the GCR correlation has identified the call as an intra BSS 
call and LCLS is allowed in the BSS, the tBSS returns the ASSIGMENT COMPLETE message with the 
LCLS -BSS -Status IE indicating "Call not yet locally switched". 

b) Since the GCR correlation has identified the call as an intra BSS call and LCLS is allowed in the BSS, the 
oBSS signals the LCLS status change to the oMSC server by sending the LCLS_NOTIFICATION message 
with the LCLS -BSS -Status IE set to "Call not yet locally switched". 

36. The tUE reports alerting. 

37. The tMSC server requests the tMGW to provide a ring-back tone. 

38. The tMSC server sends a 180 Ringing provisional response with the encapsulated ACM message to the 
preceding node. 

39. The iMSC server replies to succeeding node with the PRACK request to confirm the reception of the 180 
Ringing provisional response. 

40. The iMSC server transfers the 180 Ringing provisional response with the encapsulated ACM message to the 
preceding node. 
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41. The oMSC server replies to succeeding node with the PRACK request to confirm the reception of the 180 
Ringing provisional response. 

42. The tMSC server confirms the reception of the PRACK request with the 200 OK final response. 

43. The oMSC server reports alerting. 

44. The IMSC server confirms the reception of the PRACK request with the 200 OK final response. 

45. The tUE answers the call. 

46. The tMSC server returns the CONNECT ACKNOWLEDGE message to the tUE. 

47. The tMSC server indicates to the tBSS that this call leg is ready to be locally switched by sending the 
LCLS_CONNECT_CONTROL message. 

48. The tBSS returns the LCLS_CONNECT_CONTROL_ACK message with the LCLS-BSS-Status IE set to 
"Call not yet locally switched" since the BSS has not received the same order from the oMSC server. 

49. When the tMSC server receives the Connect message it requests the tMGW to stop providing ring-back tone 
to the calling party and requests to bothway through-connect the bearer. 

50. The tMSC server returns the 200 OK (INVITE) final response with the encapsulated ANM message with the 
LCLS-Status IE indicating "LCLS is feasible but not yet connected". 

5 1 . The oMSC server receives the 200 OK (INVITE) final response with the encapsulated ANM message with 
the LCLS-Status IE indicating "LCLS is feasible but not yet connected". 
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52. The oMSC server replies to the succeeding node with the ACK request to confirm the reception of the 200 
OK final response. 
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53. The oMSC server request the oMGW to both way through-connect the bearer. 

54. The iMSC server transfers the ACK request to the succeeding node. 

55. The oMSC server reports Answer/Connect to the oUE. 

56. The oUE returns the CONNECT ACKNOWLEDGE message to the oMSC server. 

57. The oMSC server requests the oBSS to connect LCLS since the received 200 OK (INVITE) final response 
indicated "LCLS is feasible but not yet connected". 

58. a) Since the BSS has received the through connect request for both call legs the oBSS returns the 
LCLS_CONNECT_CONTROL_ACK message with the LCLS -BSS -Status IE set to "call is locally switched 
with requested LCLS configuration" . 

b) The tBSS signals the LCLS status change to the tMSC server by sending the LCLS_NOTIFICATION 
message with the LCLS-BSS-Status IE set to "call is locally switched with requested LCLS configuration". 

c) If the oMSC server supports the option to configure its Access MGW to isolate the access side 
termination from the network side termination and LCLS negotiation indicated that no succeeding node 
requires the UL data from the oUE then the oMSC server requests the oMGW to isolate the access side 
termination Tl from the network side termination T2. 

d) If the tMSC server supports the option to configure its Access MGW to isolate the access side termination 
from the network side termination and LCLS negotiation indicated that no preceding node requires the UL 
data from the tUE then the tMSC server requests the tMGW to isolate the access side termination T4 from 
the network side termination T3. 

NOTE: The MSC server can also use the Change Through-Connection procedure and requests the MGW 
to change the through-connection of the bearer to inactive instead of using of the Isolate Bearer 
termination procedure, see 3GPP TS 23.205 [2]. 

59. The oMSC server signals the change of the LCLS status through the Core Network by sending the INFO 
request with the encapsulated APM message with the LCLS-Status IE set to "LCLS connected". 

60. The iMSC server returns the 200 OK (INFO) final response to the preceding node. 
6L The iMSC server transfers the change of the LCLS status to the succeeding node. 
62. The tMSC server returns the 200 OK (INFO) final response to the preceding node. 

6.3.5 LCLS established, Basic Call Example with BICC based CS core 
network, backward bearer establishment 

Figures 6.3.5.1 and 6.3.5.2 show the message sequence example for the basic call establishment for LCLS. In this 
example the oUE and the tUE belong to the same BSS (marked as oBSS and tBSS) and the CN permits LCLS. The 
example is based on examples from 3GPP TS 23.205 [2] for the basic mobile originating call, backward bearer 
establishment (case when access bearer assignment is completed before sending of initial address message) and the 
basic mobile terminating call, backward bearer establishment. 
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Figure 6.3.5.1 : Basic Call Establishment Flow when call is locally switched, backward bearer 

establishment 

1. Service Request handling. 

2. Originating Call SETUP. 

3. The oMSC server replies with the CALL PROCEEDING message to indicate that the call is being processed. 

4. If the oMSC server supports LCLS it retrieves the oBSS ID and generates the Global Call Reference for the 
call. 

5. Before the network side bearer information is seized the oMSC server requests the seizure of the access side 
bearer termination. 

6. The oMSC server includes a preHminary LCLS -Configuration IE in the ASSIGNMENT REQUEST message 
along with the GCR IE, because the oMSC server does not know whether LCLS is allowed in the core 
network at this stage. 

7. The oBSS returns the ASSIGNMENT COMPLETE message with the LCLS -BSS -Status IE indicating "call 
not possible to be locally switched". 

8. The oMSC server prepares the seizure of the network side bearer termination. 
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9. Afer the oMGW has repHed with the bearer address and the binding reference, the oMSC server sends the 
lAM to the succeeding node, in which the oMSC server indicates that backward bearer estabUshment is to be 
used. The oMSC server sends the lAM message including supported codecs Hst, GCR with encapsulated 
oBSS ID, and configures the LCLS -Negotiation IE. 

10. When the initial address and the bearer information is received the iMSC server requests the seizure of the 
network side bearer termination. 

1 1 . The iMSC server prepares the seizure of the outgoing side bearer termination. 

12. Afer the iMGW has replied with the bearer address and the binding reference, the iMSC server sends the 
lAM to the succeeding node. If the iMSC server supports LCLS it may modify the LCLS -Negotiation IE due 
to CAMEL, supplementary service requirements etc. before sending the I AM message containing the GCR 
with the encapsulated oBSS ID and the LCLS -Negotiation IE. 
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Figure 6.3.5.2: Basic Call Establishment when call is locally switched, backward bearer 
establishment (continuation of figure 6.3.5.1) 

1 3 . The tMSC server pages the tUE. 

14. The tMSC server performs call Setup. 

15. The tUE confirms the call. 
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16. The tMSC server requests the tMGW to estabUsh a bearer to the given iMGW. 

17. The tMSC server requests the seizure of the access side bearer termination. 

18. If the tMSC server supports the optional "intra-Network call detection" procedure it compares its own 
Network ID with the Network ID received within the Global Call Reference IE. 

If the tMSC server supports the optional "intra-BSS call detection" procedure it compares the BSS ID of the 
selected terminating BSS with the oBSS ID received within the Global Call Reference IE at this step. Since 
the oUE and the tUE belong to the same BSS the call continues the same way as for the basic LCLS 
establishment without this pre-check. 

19. The tMSC server performs the access bearer assignment and sends the ASSIGNMENT REQUEST message 
containing the GCR IE and the LCLS -Configuration IE if LCLS is permitted in the core network. 

20. The oBSS/tBSS performs the GCR correlation. Since the GCR correlation has identified the call as an intra 
BSS call and LCLS is allowed in the BSS, the tBSS returns the ASSIGMENT COMPLETE message with the 
LCLS -BSS -Status IE indicating "Call not yet locally switched". 

21. Since the GCR correlation has identified the call as an intra BSS call and LCLS is allowed in the BSS, the 
oBSS signals the LCLS status change by sending the LCLS_NOTIFICATION message with the LCLS-BSS- 
Status IE set to "Call not yet locally switched". 

22. The tUE reports alerting. 

23. The tMSC server returns the ACM message and includes the LCLS -Negotiation IE if LCLS is supported. 

24. The tMSC requests the tMGW to provide a ring-back tone. 

25. The iMSC server returns the ACM message and includes the LCLS -Negotiation IE. 

26. The oMSC server reports alerting. 

27. When performing further call establishment see figure 6.3.2.3. 



Call Clearing and LCLS Break/Re-establishment 



7.1 Call Clearing 



The call clearing procedures shall be performed in accordance with 3GPP 23.205 [2] for a BICC based CS core network 
and in accordance with 3GPP TS 23.231 [3] for a SIP-I based CS core network. 

7.2 LCLS Break 

7.2.1 MSC server Initiated 
7.2.1.1 Principles 

When the MSC server determines that local switching should be disconnected: 

- it shall send a LCLS Status Change Request message indicating disconnection preparation through the Core 
Network. 

- on receipt of a LCLS Status Change Request Acknowledge message indicating disconnection preparation with a 
Result code indicating LCLS Status Change Request accepted the MSC server shall send a LCLS -Connection- 
Control message indicating LCLS break to the associated BSS. 

On receipt of the LCLS Status Change Request message indicating disconnection preparation the MSC server shall: 

- send a LCLS break request immediately to the associated BSS, and 
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- when the acknowledge message is received from the BSS, the MSC server shall return the LCLS Status Change 
Request Acknowledge message indicating disconnection preparation and a Result code indicating LCLS Status 
Change Request accepted. 

The BSS needs to receive the LCLS break request on both call legs before releasing local switching. 

7.2.1 .2 MSC server actions 

When the MSC server determines that local switching should be disconnected it shall send to the succeeding (or 
preceding) node the LCLS Status Change Request message with the LCLS-Status-Change IE set to "LCLS- 
Disconnection-Preparation" . If in the related MGW the access side termination is isolated from the network side 
termination, the MSC Server shall request the MGW to through-connect the access side termination to the network side 
termination. 

On the reception of the LCLS Status Change Request Acknowledge message with the LCLS-Status-Change IE set to 
"LCLS -Disconnection-Preparation" and a Result code IE indicating LCLS Status Change Request accepted, the MSC 
server shall send to the BSS the LCLS-Connect-Control message with the LCLS -Connection-Status-Control IE set to 
"Release LCLS". At reception of the LCLS-Connect-Control Acknowledge message with the LCLS -BSS -Status IE set 
to "the call is no longer locally switched", the MSC server shall send to the succeeding (or preceding) node the LCLS 
Status Update message with the LCLS-Status IE set to "LCLS Not Connected" if the same LCLS Status Update 
message was not already received from the succeeding (or preceding) node. 

When the MSC server receives the LCLS Status Change Request message with the LCLS-Status-Change IE set to 
"LCLS -Disconnection-Preparation" it shall send to the BSS the LCLS-Connect-Control message with the LCLS- 
Connection-Status-Control IE set to "Release LCLS". If in the related MGW the access side termination is isolated from 
the network side termination, the MSC Server shall request the MGW to through-connect the access side termination to 
the network side termination. On reception of the LCLS-Connect-Control Acknowledge message the MSC server shall 
send to the preceding (or succeeding) node the LCLS Status Change Request Acknowledge message with the LCLS- 
Status-Change IE set to "LCLS -Disconnection-Preparation" and a Result code IE indicating LCLS Status Change 
Request accepted. 

When the LCLS-Connect-Control Acknowledge or the LCLS -Notification message with the LCLS -BSS -Status IE set to 
"the call is no longer locally switched" is received, the MSC server shall send to the succeeding (or preceding) node the 
LCLS Status Update message with the LCLS-Status IE set to "LCLS Not Connected" if the same LCLS Status Update 
message was not already received from the succeeding (or preceding) node. 

7.2.1 .3 GMSC server actions 

On receipt of the LCLS Status Change Request message with the LCLS-Status-Change IE set to "LCLS-Disconnection- 
Preparation" from the preceding (or succeeding) node, the GMSC Server shall forward message to the succeeding (or 
preceding) node. 

The GMSC Server shall forward the received LCLS Status Change Request Acknowledge message with the LCLS- 
Status-Change IE set to "LCLS -Disconnection-Preparation" and the Result code IE indicating LCLS Status Change 
Request accepted. 

On receipt of the LCLS Status Update message with the LCLS-Status IE set to "LCLS Not Connected" from the 
preceding (or succeeding) node: 

- the GMSC Server shall forward the message to the succeeding (or preceding) node if the same request was not 
already received from the succeeding (or preceding) node. 

- the GMSC Server shall not forward the message if the same request was already received from the succeeding 
(or preceding) node. 

7.2.1.4 BSS actions 

On receipt of the LCLS-Connect-Control message with the LCLS-Connection-Status-Control IE set to "Release LCLS" 
the following applies: 

- if the request was received for only one call leg associated to the LCLS call, the BSS shall not break the local 
switching. The BSS shall only send the LCLS-Connect-Control Acknowledge message to the MSC server with 
LCLS-BSS-Status indicating LCLS is still estabHshed. 
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- if the request was received for both call legs associated to the LCLS call, the BSS shall break local switching and 
shall report the LCLS disconnection on both call legs by sending: 

- the LCLS-Connect-Control Acknowledge message to the MSC server and 

- the LCLS -Notification message to the far end MSC server which previously requested LCLS release for the 
associated leg. 

7.2.2 BSS Initiated 

7.2.2.1 Principles 

When the BSS determines that local switching should be disconnected it may: 
immediately break local switching and then inform the Core Network, or 

- first request the Core Network to prepare for LCLS break and on the reception of LCLS break request on both 
call legs the BSS breaks local switching. 

7.2.2.2 Immediate LCLS break 

7.2.2.2.1 BSS actions 

When the BSS determines that local switching should be disconnected it shall immediately break local switching. The 
BSS shall report the LCLS disconnection by sending the LCLS -Notification message with the LCLS -BSS -Status IE set 
to "the call is no longer locally switched" to both MSC servers associated to the LCLS call. 

7.2.2.2.2 MSC server actions 

At reception of the LCLS -Notification message with the LCLS -BSS -Status IE set to "the call is no longer locally 
switched", the MSC server shall send to the succeeding (or preceding) node the LCLS Status Update message with the 
LCLS-Status IE set to "LCLS Not Connected" if the same LCLS Status Update message was not already received from 
the succeeding (or preceding) node. If in the related MGW the access side termination is isolated from the network side 
termination, the MSC Server shall request the MGW to through-connect the access side termination to the network side 
termination. 

7.2.2.2.3 GMSC server actions 

On receipt of the LCLS Status Update message with the LCLS-Status IE set to "LCLS Not Connected" from the 
preceding (or succeeding) node: 

- the GMSC Server shall forward the message to the succeeding (or preceding) node if the same request was not 
already received from the succeeding (or preceding) node. 

- the GMSC Server shall not forward the message if the same request was already received from the succeeding 
(or preceding) node. 

7.2.2.3 BSS Requesting LCLS Release from Core Network 
7.2.2.3.1 BSS actions 

When the BSS determines that local switching should be disconnected but the LCLS release should be ordered from the 
Core Network the BSS shall request the LCLS disconnection by sending the LCLS -Notification message with a LCLS- 
Break-Request IE to both MSC servers associated to the LCLS call. 

On receipt of the LCLS-Connect-Control message with the LCLS-Connection-Status-Control IE set to "Release LCLS" 
the BSS shall apply the procedure described in sub-clause 7.2.1.4. 
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7.2.2.3.2 MSC server actions 

At reception of the LCLS -Notification message with LCLS -Break-Request IE the MSC server shall send to the 
succeeding (or preceding) node the LCLS Status Change Request message with the LCLS-Status-Change IE set to 
"LCLS -Disconnection-Preparation". If in the related MGW the access side termination is isolated from the network side 
termination, the MSC Server shall request the MGW to through-connect the access side termination to the network side 
termination. 

On the reception of the LCLS Status Change Request message with the LCLS-Status-Change IE indicating LCLS 
disconnection preparation, the MSC server shall apply the procedure described in sub-clause 7.2. L2 with the following 
exception: 

- on the reception of the LCLS Status Change Request Acknowledge message with the LCLS-Status-Change IE 
set to "LCLS -Disconnection-Preparation" and a Result code IE indicating LCLS Status Change Request 
accepted the MSC server shall not request the LCLS break if it already requested due to the reception of the 
LCLS Status Change Request message from the succeeding (or preceding) node. 

7.2.2.3.3 GMSC server actions 

The GMSC server shall perform the same actions as described in sub-clause 7.2. L3. 

7.2.3 Intermediate Node/GMSC Server Initiated 

7.2.3.1 Principles 

When an intermediate node or a GMSC server determines that local switching should be disconnected it shall send the 
LCLS Status Change Request message indicating disconnection preparation to the preceding and to the succeeding 
node. 

On receipt of LCLS Status Change Request message indicating disconnection preparation the originating or terminating 
MSC server shall send LCLS break request immediately to the associated BSS. When the acknowledge message is 
received from the BSS, the MSC server shall return LCLS Status Change Request Acknowledge message indicating 
disconnection preparation and a Result code indicating LCLS Status Change Request was accepted. 

The BSS needs to receive the LCLS break request on both call legs before releasing local switching. 

7.2.3.2 Intermediate Node/GMSC server actions 

When an intermediate node or a GMSC server determines that local switching should be disconnected it shall send the 
LCLS Status Change Request message with the LCLS-Status-Change IE set to "LCLS -Disconnection-Preparation" to 
the preceding and to the succeeding node. 

The intermediate node or the GMSC Server not initiating the LCLS break shall forward the received LCLS Status 
Change Request message with the LCLS-Status-Change IE set to "LCLS -Disconnection-Preparation". 

On receipt of the LCLS Status Change Request Acknowledge message with the LCLS-Status-Change IE set to "LCLS- 
Disconnection-Preparation" and a Result code IE indicating LCLS Status Change Request was accepted from the 
preceding (or succeeding) node, the intermediate node or the GMSC Server not initiating the LCLS break shall forward 
message to the succeeding (or preceding) node. 

On receipt of the LCLS Status Update message with the LCLS-Status IE set to "LCLS Not Connected" from the 
preceding (or succeeding) node: 

- the intermediate node or the GMSC Server not initiating the LCLS break shall forward the message to the 
succeeding (or preceding) node. 

- the intermediate node or the GMSC Server initiating the LCLS break shall not forward the message. 

7.2.3.3 MSC server actions 

When the LCLS Status Change Request message with the LCLS-Status-Change IE set to "LCLS -Disconnection- 
Preparation" is received from the succeeding (or preceding) node, the MSC Server shall send to the BSS the LCLS- 
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Connect-Control message with the LCLS -Connection-Status-Control IE set to "Release LCLS". If in the related MGW 
the access side termination is isolated from the network side termination, the MSC Server shall request the MGW to 
through-connect the access side termination to the network side termination. 

If the LCLS -Connect-Control Acknowledge message with the LCLS-BSS-Status IE set to "call is locally switched with 
requested LCLS configuration" is received, the MSC server shall send to the preceding (or succeeding) node the LCLS 
Status Change Request Acknowledge message with the LCLS-Status-Change IE set to "LCLS -Disconnection- 
Preparation" and a Result code IE indicating LCLS Status Change Request accepted. 

At reception of the LCLS -Notification message with the LCLS-BSS-Status IE set to "the call is no longer locally 
switched", the MSC server shall send to the succeeding (or preceding) node the LCLS Status Update message with the 
LCLS-Status IE set to "LCLS Not Connected". 

At reception of the LCLS -Connect-Control Acknowledge message with the LCLS-BSS-Status IE set to "the call is no 
longer locally switched", after sending the LCLS Status Change Request Acknowledge message, the MSC server shall 
send to the succeeding (or preceding) node the LCLS Status Update message with the LCLS-Status IE set to "LCLS 
Not Connected" . 

7.2.3.4 BSS actions 

The BSS shall perform the same actions as described in sub-clause 7.2.1.4. 



7.2.4 LCLS Break Example Call Flows 



7.2.4.1 



LCLS Break Connection Model for LCLS 



Figure 7.2.4.1.1 shows the network model for a LCLS break of the mobile call. The "squared" line represents the call 
control signalling. The "dotted/full" line represents the bearer terminations in the MGW. Bearer termination Tl and T6 
are used for the bearer towards BSC and bearer termination T2, T3, T4 and T5 are used for the bearer towards 
preceding/succeeding MGW. 



Control plane link which transmits signalling 

User plane link path through CN 

User plane link which transmits real user plane data 



tUE 



oUE 




Connection Model 1 : Before LCLS Break 
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tUE 



oUE 




Connection Model 2: After LCLS Break 
Figure 7.2.4.1.1: LCLS Break (Network model) 

7.2.4.2 MSC server Initiated 

Figure 7.2.4.2.1 shows the message sequence example for the MSC server initiated LCLS Break. 
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Figure 7.2.4.2.1 : MSC Server initiated LCLS break 
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1 . The oMSC server determines that local switching should be disconnected. 

2. The oMSC server sends to the succeeding node the LCLS Status Change Request message with the LCLS- 
Status-Change IE set to "LCLS -Disconnection-Preparation". 

3. The iMSC server transfers the LCLS Status Change Request message to the succeeding node. 

4. The tMSC server sends to the tBSS the LCLS-Connect-Control message with the LCLS-Connection-Status- 
Control IE set to "Release LCLS". 

5. The tBSS confirms the reception of the LCLS release request with the LCLS-Connect-Control Acknowledge 
message but does not change the LCLS-BSS status since LCLS release request is not yet received for the 
associated call leg. 

6. The tMSC server sends to the preceding node the LCLS Status Change Request Acknowledge message with 
the LCLS-Status-Change IE set to "LCLS -Disconnection-Preparation" and the Result code IE set to LCLS 
Status Change Request accepted. 

7. The iMSC server transfers the LCLS Status Change Request Acknowledge message to the preceding node. 

8. The oMSC server sends to the oBSS the LCLS-Connect-Control message with the LCLS -Connection-Status- 
Control IE set to "Release LCLS". 

9. The BSS reports the LCLS disconnection by sending: 

a) The LCLS-Connect-Control Acknowledge message with the LCLS -BSS -Status IE set to "the call is no 
longer locally switched" to the oMSC server. 

b) The LCLS -Notification message with the LCLS -BSS -Status IE set to "the call is no longer locally 
switched" to the tMSC server. 

10. The oMSC server sends the LCLS Status Update Request message with the LCLS-Status IE set to "LCLS 
Not Connected" to the succeeding node. 

11. The iMSC server transfers the LCLS Status Update message to the succeeding node. 

12. On the receipt of the LCLS -Notification message with the LCLS -BSS -Status indicating LCLS disconnection 
the tMSC server sends the LCLS Status Update message with the LCLS-Status IE set to "LCLS Not 
Connected" to the preceding node. 

NOTE: The iMSC server does not forward the LCLS Status Update message since the same LCLS Status 
is already received from the oMSC server. 

7.2.4.3 BSS Initiated, Immediate LCLS Break 

Figure 7.2.4.3.1 shows the message sequence example for the BSS initiated LCLS Break. 
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1. Locally switched 
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Figure 7.2.4.3.1 : BBS initiated, immediate LCLS break 

1. The BSS determines that local switching should be disconnected. 

2a, b. The BSS reports the LCLS disconnection by sending the LCLS -Notification message with the LCLS-BSS- 
Status IE set to "the call is no longer locally switched" to the tMSC server and oMSC server. 

3. a) The tMSC server sends the LCLS Status Update message with the LCLS-Status IE set to "LCLS Not 
Connected" to the preceding node. 

b) The oMSC server sends the LCLS Status Update message with the LCLS-Status IE set to "LCLS Not 
Connected" to the succeeding node. 

4a. The iMSC server transfers the LCLS Status Update message to the oMSC server. 

NOTE: At reception of the LCLS Status Update message from the oMSC server, the iMSC server does not 
forward the LCLS Status Update message since the same LCLS Status is already received from the 
tMSC server. 



7.2.4.4 



BSS Initiated, LCLS Break requested from Core Network 



Figure 7.2.4.4.1 shows the message sequence example for the BSS initiated but when the LCLS Break is requested from 
the Core Network. 
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Figure 7.2.4.4.1 : BBS initiated, LCLS Release ordered from Core Network 

1. The BSS determines that local switching should be disconnected. 

2a, b. The BSS requests the LCLS disconnection by sending the LCLS -Notification message with LCLS-Break- 
Request IE set to "LCLS Break Request" to the oMSC server and tMSC server. 

3. a) The oMSC server sends to the succeeding node the LCLS Status Change Request message with the 
LCLS -Status-Change IE set to "LCLS-Disconnection-Preparation". 

b) The tMSC server sends to the preceding node the LCLS Status Change Request message with the LCLS- 
Status-Change IE set to "LCLS-Disconnection-Preparation". 

4a, b. The iMSC server transfers the LCLS Status Change Request message to the succeeding/preceding node. 

5. a) The tMSC server sends to the tBSS the LCLS-Connect-Control message with the LCLS -Connection- 
Status-Control IE set to "Release LCLS". 

b) The oMSC server sends to the oBSS the LCLS-Connect-Control message with the LCLS -Connection- 
Status-Control IE set to "Release LCLS". 

6. a) The tBSS confirms the reception of the LCLS release request with the LCLS-Connect-Control 
Acknowledge message but does not change the LCLS -BSS status since LCLS release request is not yet 
received for the associated call leg. 

b) The oBSS reports the LCLS disconnection by sending the LCLS-Connect-Control Acknowledge message 
with the LCLS -BSS -Status IE set to "the call is no longer locally switched" to the oMSC server. 
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c) The tBSS reports the LCLS disconnection by sending the LCLS -Notification message with the LCLS- 
BSS-Status IE set to "the call is no longer locally switched to the tMSC server. 

7. a) On the receipt of the LCLS-Connect-Control Acknowledge message with the LCLS-BSS status still 
indicating local switching the tMSC server sends to the preceding node the LCLS Status Change Request 
Acknowledge message with the LCLS-Status-Change IE set to "LCLS -Disconnection-Preparation" and the 
Result code IE set to LCLS Status Change Request accepted. 

b) On the receipt of the LCLS-Connect-Control Acknowledge message the oMSC server sends to the 
succeeding node the LCLS Status Change Request Acknowledge message with the LCLS-Status-Change IE 
set to "LCLS -Disconnection-Preparation" and the Result code IE set to LCLS Status Change Request 
accepted. 

8. a) The iMSC server transfers the LCLS Status Change Request Acknowledge message to the preceding 
node. 

b) The iMSC server transfers the LCLS Status Change Request Acknowledge message to the succeeding 
node. 

NOTEl : The oMSC server already requested the LCLS break from the oBSS (step 5b) and due to that it 
does not perform any action on the receipt of the LCLS Status Change Request Acknowledge 
message. The tMSC server does not perform any action on the receipt of the LCLS Status Change 
Request Acknowledge message since it already requested the LCLS break from the tBSS (step 5a) 
and already received LCLS -Notification message indicating LCLS disconnection (step 6c). 

9. At reception of the LCLS-Connect-Control Acknowledge message indicating LCLS disconnection the oMSC 
server sends the LCLS Status Update message with the LCLS-Status IE set to "LCLS Not Connected" to the 
succeeding node. 

10. The iMSC server transfers the LCLS Status Update message to the succeeding node. 

11. On the receipt of the LCLS -Notification message indicating LCLS disconnection the tMSC server sends the 
LCLS Status Update message with the LCLS-Status IE set to "LCLS Not Connected" to the preceding node. 

N0TE2: At reception of the LCLS Status Update message from the tMSC server, the iMSC server does not 
forward the LCLS Status Update message since the same LCLS Status is already received from the 
oMSC server. 

7.2.4.5 Intermediate Node/GMSC Server Initiated 

Figure 7.2.4.5.1 shows the message sequence example for the network initiated LCLS Break. 
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Figure 7.2.4.5.1 : Intermediate Node / GMSC Server initiated LCLS break 

1 . The iMSC server determines that local switching should be disconnected. 

2a, b. The iMSC server send the LCLS Status Change Request message with the LCLS-Status-Change IE set to 
"LCLS -Disconnection-Preparation" to the preceding node and to the succeeding node. 

3. a) The oMSC server sends to the oBSS the LCLS-Connect-Control message with the LCLS -Connection- 
Status-Control IE set to "Release LCLS". 

b) The tMSC server sends to the tBSS the LCLS-Connect-Control message with the LCLS -Connection- 
Status-Control IE set to "Release LCLS". 

4. a) The oBSS confirms the reception of the LCLS release request but does not change the LCLS-BSS status 
since LCLS release request is not yet received for the associated call leg. 

b) The tBSS reports the LCLS disconnection by sending the LCLS-Connect-Control Acknowledge message 
with the LCLS-BSS -Status IE set to "the call is no longer locally switched" to the tMSC server. 

c) The oBSS reports the LCLS disconnection by sending the LCLS -Notification message with the LCLS- 
BSS-Status IE set to "the call is no longer locally switched" to the oMSC server. 

5. a) On the receipt of the LCLS-Connect-Control Acknowledge message with the LCLS-BSS status still 
indicating local switching the oMSC server sends to the succeeding node the LCLS Status Change Request 
Acknowledge message with the LCLS-Status-Change IE set to "LCLS -Disconnection-Preparation" and the 
Result code IE set to LCLS Status Change Request accepted. 

b) On the receipt of the LCLS-Connect-Control Acknowledge message the tMSC server sends to the 
preceding node the LCLS Status Change Request Acknowledge message with the LCLS-Status-Change IE 
set to "LCLS -Disconnection-Preparation" and the Result code IE set to LCLS Status Change Request 
accepted. 
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NOTEl : Since the LCLS disconnection is ordered by the iMSC server it does not forward the LCLS Status 
Change Request Acknowledge message to the succeeding node. 

6. a) At reception of the LCLS-Connect-Control Acknowledge message indicating LCLS disconnection the 
tMSC server sends the LCLS Status Update message with the LCLS-Status IE set to "LCLS Not Connected" 
to the preceding node. 

b) On the receipt of the LCLS -Notification message the oMSC server sends the LCLS Status Update 
message with the LCLS-Status IE set to "LCLS Not Connected" to the succeeding node. 

N0TE2: Since the LCLS disconnection is ordered by the iMSC server it does not forward the LCLS Status 
Update message to the preceding/succeeding node. 

7.2.4.6 MSC server Initiated when Access Side Termination is isolated in MGW 

Figure 7.2.4.6.1 shows the message sequence example for the MSC server initiated LCLS Break for the case when the 
LCLS negotiation through the Core Network enabled the MSC server to use the option to isolate access side termination 
from the network side termination. 

In this example the oMSC server moves the originating UE (access side termination Tl) back to the context oC with 
network side termination T2 and requests the oMGW to be bothway through-connected after the oMSC server 
determined that local switching should be disconnected and sent to the succeeding node the LCLS Status Change 
Request message indicating LCLS disconnection preparation. 




2b. MO^/ request (Tl) / MOV reply 



2a. LCLS Sta(us 

[LCLS-Status- 

Disconnectior 



Change Request: APM 
Change = "LCLS- 
Preparation"] 



Context oC 

Join Bearer "dermination 



For succeeding signaling sequences see figure 7.2.4.2.1 steps 3 - 12 



Figure 7.2.4.6.1 : MSC initiated LCLS break, access side termination isolated in MGW 

1 . The oMSC server determines that local switching should be disconnected. 

2. The oMSC server sends to: 

a) the succeeding node the LCLS Status Change Request message with the LCLS -Status-Change IE set to 
"LCLS -Disconnection-Preparation"; 

b) the oMGW request to move the access side termination Tl to context oC with the network side 
termination T2; 

NOTE 1 : Steps 2a and 2b can be performed in parallel. 

NOTE 2: If the MSC server has previously used the Change Through-Connection procedure and requested 
the MGW to change the through-connection of the bearer to inactive instead of using the Isolate 
Bearer termination procedure then the MSC server will use the Change Through-Connection 
procedure to request the MGW to change the through-connection of the bearer to be both- way 
through-connected. 

3. The further steps are performed as defined in sub-clause 7.2.4.2, steps 3-12. 
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7.3 LCLS Re-establishment 
7.3.1 MSC server Initiated 

7.3.1.1 Principles 

The following Re-establishment procedures describe the scenario when a node has requested an LCLS -break for a 
temporary period while applying a supplementary service or CN intervention and once completed wishes to resume the 
LCLS connection. If the node which broke the LCLS does not re-establish the LCLS via these procedures, LCLS can 
also be re-established by another interaction such as handovers (as specified in clause 8) or subsequent LCLS 
negotiations (e.g. due to supplementary service interaction). If a node in the path does not accept the LCLS Status 
Change Request (e.g. re-establishment) it shall respond with a LCLS Status Change Request Acknowledge message 
containing a Result Code IE set to "Status Change Request rejected", and not forward the LCLS Status Change Request 
to the succeeding (or preceding) node. 

7.3.1 .2 MSC server actions 

7.3.1 .2.1 LCLS re-establishment to the network side 

The MSC server which initiates LCLS re-establishment shall send the LCLS Status Change Request message with the 
LCLS -Status-Change IE to the succeeding (or preceding) node to requests a change in LCLS Status in the CN. 

Once the LCLS Status Change Request message with the LCLS -Status-Change IE set to "LCLS -Connection- 
Preparation" is received from the preceding (or succeeding) node, the MSC server shall check if the requested LCLS 
Status is allowed and shall send the LCLS Status Change Request Acknowledge message with the correct LCLS -Status- 
Change IE value and with a Result code back to the preceding (or succeeding) node. The Result code indicates whether 
LCLS Status Change Request is accepted or not. 

7.3.1 .2.2 LCLS re-establishment to the BSS 

Once the LCLS -Status-Change Request message with LCLS -Status-Change IE or the LCLS -Status-Change Request 
Acknowledge message with the LCLS-Status-Change IE sent from the preceding (or succeeding) node is received, the 
MSC sever shall check if the requested LCLS Status is allowed or not and if it is allowed then the MSC Server shall 
send the LCLS-CONNECT-CONTROL message with LCLS-Connection-Status-Control set to "connect" to the BSS 

7.3.1 .2.3 LCLS Status update to the network side 

Once the LCLS -Notification message or LCLS-Connect-Control-ACK message sent from BSS is received by MSC 
server, and if the received LCLS -BSS -Status indicates local switching, the MSC server shall send to the succeeding (or 
preceding) node the LCLS Status Update message with the LCLS-Status IE set to "LCLS Connected" if the same LCLS 
status update is not already received from the succeeding (or preceding) node.. 

7.3.1 .3 GMSC server actions 

Once the LCLS Status Change Request message with the LCLS-Status-Change IE sent from preceding (or succeeding) 
node is received, the GMSC sever shall check if the requested LCLS Status is allowed or not and if it is allowed the 
GMSC server shall forward the LCLS Status Change Request message with correct value to the succeeding (or 
preceding) node. 

At the reception of the LCLS-Status-Change Request Acknowledge message from the succeeding/preceding node the 
GMSC server shall forward the received message to the preceding/succeeding node. 

Once the LCLS -Status-Update message with the LCLS Status IE sent from preceding/succeeding node is received by 
GMSC server, 

- the GMSC Server shall forward the message to the succeeding/preceding node if the same request is not already 
received from the succeeding/preceding node. 

- the GMSC Server shall not forward the message if the same request is already received from the 
succeeding/preceding node. 
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7.3.1.4 BSS actions 

On receipt of the LCLS-Connect-Control message with the LCLS-Connection-Status-Control IE set to "connect LCLS" 
the BSS may estabUsh LCLS (following the principles described in sub-clause 4.4) and notify the CN as described for 
LCLS call establishment. 

7.3.2 BSS Initiated 

BSS Initiated LCLS re-establishment is not supported for LCLS. 

7.3.3 Intermediate Node / GMSC Server Initiated 

7.3.3.1 Principles 

The following Re-establishment procedures describe the scenario when a node has requested an LCLS -break for a 
temporary period while applying a supplementary service or CN intervention and once completed wishes to resume the 
LCLS connection. If the node which broke the LCLS does not re-establish the LCLS via these procedures, LCLS can 
also be re-established by another interaction such as handovers (as specified in clause 8) or subsequent LCLS 
negotiations (e.g. due to supplementary service interaction). If a node in the path does not accept the LCLS Status 
Change Request (e.g. re-establishment) it shall respond with a LCLS Status Change Request Acknowledge message 
containing a Result Code IE set to "Status Change Request rejected", and not forward the LCLS Status Change Request 
to succeeding/preceding node. 

7.3.3.2 Intermediate Node / GMSC server actions 

When an intermediate node or the GMSC server determines that local switching should be re-established it shall send 
the LCLS Status Change Request message with the LCLS -Status-Change IE set to "LCLS -Connection-Preparation" to 
the preceding and to the succeeding node. 

The intermediate node or the GMSC Server not initiating the LCLS re-establishment shall check if the requested LCLS 
Status is allowed or not and if it is allowed the intermediate node shall forward the received LCLS Status Change 
Request message. 

On receipt of the LCLS Status Change Request Acknowledge message with the LCLS -Status-Change IE set to "LCLS 
Connection Preparation" and a Result code IE from the preceding/succeeding node, the intermediate node or the GMSC 
Server not initiating the LCLS re-establishment shall forward message to the succeeding/preceding node. The Result 
code indicates whether LCLS Status Change Request is accepted or not. 

On receipt of the LCLS Status Update message with the LCLS-Status IE set to "LCLS Connected" from the 
preceding/succeeding node: 

- the intermediate node or the GMSC Server not initiating the LCLS re-establishment shall forward the message to 
the succeeding/preceding node. 

- the intermediate node or the GMSC Server initiating the LCLS re-establishment shall not forward the message. 

7.3.3.3 MSC server actions 

When the LCLS Status Change Request message with the LCLS -Status-Change IE set to "LCLS Connection 
Preparation" is received from the succeeding (or preceding) node, the MSC Server shall check if the requested LCLS 
status is allowed or not and if it is allowed then the MSC Server shall send to BSS the LCLS-Connect-Control message 
with the LCLS -Connection-Status-Control IE set to "connect". The MSC server shall send LCLS Status Change 
Request Acknowledge message with the correct LCLS -Status-Change IE value and a Result code back to the preceding 
(or succeeding) node. The Result code indicates whether LCLS Status Change Request is accepted or not. 

At reception of the LCLS-Connect-Control Acknowledge message or the LCLS -Notification message with the LCLS- 
BSS-Status IE set to "Call is Locally switched with requested LCLS configuration", the MSC server shall send to the 
succeeding (or preceding) node the LCLS Status Update message with the LCLS-Status IE set to "LCLS Connected" if 
the same LCLS status update is not already received from the succeeding (or preceding) node. 
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7.3.3.4 BSS actions 

The BSS shall perform the same actions as described in sub-clause 7.3.1.4. 

7.3.4 LCLS Re-establishment Example Call Flows 



7.3.4.1 



LCLS Re-establishment Connection Model for LCLS 



Figure 7.3.4.1.1 shows the network model for a LCLS Re-establishment of the mobile call. The "squared" line 
represents the call control signalling. The "dotted/full" line represents the bearer terminations in the MGW. Bearer 
termination Tl and T6 are used for the bearer towards BSC and bearer termination T2, T3, T4 and T5 are used for the 
bearer towards preceding/succeeding MGW. 



Control plane link which transmits signalling 

User plane link path through ON 

User plane link which transmits real user plane data 



tUE 



oUE 




tUE 



oUE 



7.3.4.2 



Connection Model 1: Before LCLS Re-establishment 




Connection Model 2: After LCLS Re-establishment 
Figure 7.3.4.1.1: LCLS Re-establishment (Network model) 

MSC server Initiated Example Call Flow 



Figure 7.3.4.2.1 shows the message sequence example for the MSC server initiated LCLS Re-estabHshment. In the 
example the MSC server trigger the LCLS negotiation in the CN. The BSS establishes local switching when both legs 
are informed LCLS is allowed. 
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Figure 7.3.4.2.1 : MSC server Initiated LCLS Re-establishment 

The oMSC server determines that local switching should be re-established. The oMSC server sends to the 
succeeding node the LCLS Status Change Request message with the LCLS-Status-Change IE set to "LCLS- 
Connection-Preparation" . 

The iMSC server transfers the LCLS Status Change Request message to the tMSC server. 

The tMSC server sends LCLS Status Change Request Acknowledge message to the preceding node. 

The tMSC server sends to the tBSS the LCLS-Connect-Control message with the LCLS -Connection-Status- 
Control IE set to "connect". 



NOTE: Step 3 and 4 can be performed paralleled. 

5. The iMSC server transfers the LCLS Status Change Request Acknowledge message to the oMSC server. 

6. The oBSS confirms the reception of the LCLS connect request but does not change the LCLS -ESS status 
since LCLS connect request is not yet received for the associated call leg. 

7. On receipt of LCLS Status Change Request Acknowledge message, the oMSC server sends to the oBSS the 
LCLS-Connect-Control message with the LCLS -Connection-Status-Control IE set to "connect". 
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10. 
11. 



Because LCLS connect requests are received for the associated call leg, the oBSS/tBSS re-establish the 
LCLS. 

The oBSS reports the LCLS connection by sending the LCLS-Connect-Control Acknowledge message to the 
oMSC server. 

The tBSS reports the LCLS connection by sending the LCLS -Notification message to the tMSC server. 

The oMSC server sends the LCLS Status Update message with the LCLS-Status IE set to "LCLS Connected" 
to the succeeding node. 



12. The iMSC server transfers the LCLS Status Update message to the tMSC server. 

13. The tMSC server sends the LCLS Status Update message with the LCLS-Status IE set to "LCLS Connected" 
to the preceding node. The iMSC server does not forward the LCLS Status Update message to the oMSC 
server since the same LCLS Status is already received from the oMSC server. 



7.3.4.3 



Intermediate Node / GMSC Server Initiated Example Call Flow 



Figure 7.3.4.3.1 shows the message sequence example for the Intermediate Node / GMSC Server initiated LCLS Re- 
establishment. 
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Figure 7.3.4.3.1 : Intermediate Node / GMSC Server Initiated LCLS Re-establishment 

1 . The iMSC server determines that local switching should be established. 
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2. The iMSC server sends the LCLS Status Change Request message with the LCLS-Status-Change IE set to 
"LCLS -Connection-Preparation" to the oMSC server. 

3. The iMSC server sends the LCLS Status Change Request message with the LCLS-Status-Change IE set to 
"LCLS-Connection-Preparation" to the tMSC server. 

4. The oMSC server sends LCLS Status Change Request Acknowledge message to the succeeding node. 

5. The tMSC server sends LCLS Status Change Request Acknowledge message to the preceding node. 

6. The oMSC server sends to the oBSS the LCLS-Connect-Control message with the LCLS -Connection-Status- 
Control IE set to "connect". 

7. The oBSS confirms the reception of the LCLS connect request but does not change the LCLS-BSS status 
since LCLS connect request is not yet received for the associated call leg. 

8. The tMSC server sends to the tBSS the LCLS-Connect-Control message with the LCLS-Connection-Status- 
Control IE set to "connect". 

9a. The tBSS reports the LCLS connection by sending the LCLS-Connect-Control Acknowledge message to the 
tMSC server. 

9b. The oBSS reports the LCLS connection by sending the LCLS -Notification message to the oMSC server. 

10. The tMSC server sends the LCLS Status Update message with the LCLS-Status IE set to "LCLS Connected" 
to the preceding node. 

n. The oMSC server sends the LCLS Status Update message with the LCLS-Status IE set to "LCLS Connected" 
to the succeeding node. 

NOTE: Since LCLS re-establishment is ordered by the iMSC server it does not forward the LCLS Status Update 
message to the preceding/succeeding node. 

7.3.4.4 MSC server Initiated when Access Side Termination is isolated in MGW 

Figure 7.3.4.4.1 shows the message sequence example for the MSC server initiated LCLS Re-establishment for the case 
when the LCLS negotiation through the Core Network enabled the MSC server to use the option to isolate access side 
termination from the network side termination. 

In this example the oMSC server requests the oMGW to interrupt the communication on the bearer by using the Isolate 
Bearer Termination Procedure (i.e. to isolate access side termination Tl from the network side termination T2) after the 
oBSS re-established local switching. 
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For preceding signaling sequences see figure 7.3.4.2.1 steps 1- 10 
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Figure 7.3.4.4.1 : MSC server Initiated LCLS Re-establishment, access side termination isolated in 

MGW 

1-10. When the oMSC server determines that local switching should be re-established it initiates the LCLS Re- 
estabUshment procedure specified in sub-clause 7.3.4.2, steps 1 - 10. 

11. a) The oMSC server send to the oMGW request to isolate the access side termination Tl from the network 
side termination T2. 

NOTE 1 : The MSC server can also use the Change Through-Connection procedure and requests the MGW 
to change the through-connection of the bearer to inactive instead of using of the Isolate Bearer 
termination procedure, see 3GPP TS 23.205 [2]. 

b) The oMSC server sends the LCLS Status Update message with the LCLS-Status IE set to "LCLS 
Connected" to the succeeding node. 

NOTE 2: Steps 11a and 1 lb can be performed in parallel. 

12. The iMSC server transfers the LCLS Status Update message to the tMSC server. 

13. The tMSC server sends the LCLS Status Update message with the LCLS-Status IE set to "LCLS Connected" 
to the preceding node. The iMSC server does not forward the LCLS Status Update message to the oMSC 
server since the same LCLS Status is already received from the oMSC server. 



8 



Handover/Relocation 



8.1 



UMTS to UMTS 



For Inter-MSC Handover UMTS to UMTS the Anchor MSC server shall include the GCR IE, the LCLS -Negotiation 
Request IE and the LCLS -Configuration-Preference IE in lAM to the Target MSC server. The Target MSC server may 
modify the LCLS -Configuration-Preference IE based on its own LCLS configuration requirements. The rules for LCLS 
Configuration settings are defined in clause 4.2. The Target MSC server shall include the final LCLS -Configuration- 
Preference IE and the LCLS -Negotiation Response IE in the APM or ACM or CPG. The Target MSC server may then 
use the LCLS parameters to enable LCLS if a subsequent UTRAN to GERAN handover occurs. 
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8.2 UMTS to GSM 

8.2.1 General 

The procedures specified in 3GPP TS 23.205 [2] for BICC based CS Core Network and 3GPP 23.231 [3] for SIP-I 
based CS Core Network shall be followed. The following clauses describe the additional requirements for LCLS 
functionality. 

8.2.2 Intra-MSC UMTS to GSM Handover 

8.2.2.1 Intra-MSC UMTS to GSM Handover that establishes Local Switching 

8.2.2.1.1 General 

When LCLS is not established for a call and an intra-MSC UMTS to GSM handover occurs that makes the call local, 
the call can be locally switched in the Target BSS. The following clauses describe the additional requirements for intra- 
MSC UMTS to GSM handover that establish LCLS. 

8.2.2.1 .2 Relocation Required 

When the MSC server receives the Relocation Required message from the serving RNC, it requests the MGW to seize a 
TDM circuit if AoTDM or an IP termination if AoIP for the termination to the Target BSS as for the normal handover 
procedure. 

The MSC server sends the Handover Request message to the Target BSS as for the normal case but shall include the 
GCR IE, the LCLS -Configuration IE and the LCLS-Connection-Status-Control IE set to "Connect". 

8.2.2.1 .3 Handover Request Acknowledge 

If the Target BSS supports LCLS feature then it shall include the LCLS -BSS -Status IE in the Handover Request 
Acknowledge message in order to inform the MSC Server that the BSS supports the LCLS feature. 

8.2.2.1 .4 Handover Complete 

The target BSS sends Handover Complete including the LCLS -BSS -Status IE, which indicates to the MSC server that 
the call is locally switched. 

NOTE: The target BSS will send LCLS -Notification message to the MSC at the other call leg indicating the call 
is locally switched. 

8.2.2.1.5 Example 

8.2.2.1 .5.1 Connection Model 

Figure 8.2.2.1.5.1.1 shows the network model for the Basic Intra-MSC UMTS to GSM handover when LCLS is 
established as a result of the handover. The dashed line in green represents call control signalling and the dashed line in 
blue represents the user plane connection path via the core network, which should be used if LCLS is not established or 
after LCLS is broken. The non-dotted lines represent the bearer carrying real user plane data. In MGW-1 the bearer 
termination Ts is used for the bearer towards RNC, bearer termination Ta is used for the bearer towards the 
succeeding/preceding MGW, that is MGW-2 and bearer termination Tt is used towards the Target BSS. In MGW-2 the 
bearer termination T2 is used for the bearer towards BSS-2 and bearer termination Ti is used for the bearer towards 
MGW-1. 

In this example scenario the Handover Device is located in MGW-1 selected for the call establishment by the MSC-1 
server, which controls the call and mobility management. 
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Connection Model 3: After Handover, LCLS is established and both call legs are in Target BSS 
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Figure 8.2.2.1.5.1.1 : Basic Intra-MSC UMTS to GSM Handover (network model) 



ETSI 



3GPP TS 23.284 version 10.3.0 Release 10 



68 



ETSI TS 123 284 VI 0.3.0 (2012-01) 



8.2.2.1.5.2 



Basic Sequence for Intra-MSC UMTS to GSM Handover that establishes Local 
Switching 
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Figure 8.2.2.1.5.2.1 : Intra-MSC UMTS to GSM Handover that establishes Local Switching 

1 . lu Relocation Required message is received from the RNC requesting an intra-MSC UMTS to GSM 
handover. The call is currently not locally switched. 

2. The MSC-1 server requests the MGW-1 to reserve circuit or Connection Point towards the Target-BSS 

3. The MSC-1 server sends the Handover Request message to the Target BSS with the GCR IE, the LCLS- 
Configuration IE and the LCLS-Connection-Status-Control IE indicating "connect" to through-connect the 
local call. 

4. Target BSS performs call leg correlation with GCR to determine if another call leg is active with the same 
GCR. The Target BSS reports in Handover Request Acknowledge message that the local call was found but 
LCLS is not yet established. 

4a. The BSS-2 notifies MSC-2 server the LCLS status is changed by sending the LCLS_Notification message 
with the LCLS-BSS-Status IE set to "Call not yet locally switched". 

4b. If the call has been answered and MSC-2 server permits LCLS to be connected, then the MSC-2 server sends 
to the BSS-2 the LCLS_Connect_Control message with the LCLS-Connection-Status-Control IE set to 
"connect". 
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4c. The BSS-2 returns the LCLS_Connect_Control_ACK message with the LCLS-BSS -Status IE set to "Call not 
yet locally switched" . 

5. The MSC-1 server triggers the Relocation Command message. 

6. The UE-1 is detected at the target BSS. Then the Target BSS/BSS-2 can internally transmit the user plane 
data. 

7. In the Handover Complete message the Target-BSS indicates to the MSC-1 server in the LCLS-BSS -Status 
IE that the call has been locally switched. 

8. The MSC-1 server requests the old serving RNC to release the old call leg. 

9. The Serving BSS-2 informs the MSC-2 server that the call has been locally switched via LCLS_Notification 
message. 

10. Releasing of the old call leg to the RNC is completed. 

1 1 . The termination Ts to the old RNC is removed from the Access MGW-1 . 

12. The MSC-1 server informs succeeding CN nodes that LCLS is connected. 

NOTE : When BICC is used as the call control protocol the APM message is sent. When SIP-I is used the 
INFO request with the encapsulated APM message is sent. 

8.2.2.2 Intra-MSC UMTS to GSM Handover that does not establish LCLS 

Intra-MSC UMTS to GSM Handover that does not estabHsh LCLS follows the procedures in 8.2.2.1. The differences 
are: 

- in the step 7, the Target BSS informs MSC-1 server that the call is not locally switched in the Handover 
Complete message. 

- steps 4a, 4b, 4c, 9 and step 12 are not triggered. 

8.2.3 Inter-MSC UMTS to GSM Handover 

8.2.3.1 Inter-MSC UMTS to GSM Handover that establishes Local Switching 

8.2.3.1.1 General 

When LCLS is not established for a call and an inter-MSC UMTS to GSM handover occurs that makes the call local, 
the call can be locally switched in the Target BSS. The following clauses describe the additional requirements for inter- 
MSC handovers that estabHsh LCLS. 

8.2.3.1.2 MSC-1 /MGW-1 
8.2.3.1.2.1 Relocation Required 

8.2.3.1.2.1 Relocation Required 

When MSC-1 Server receives the Relocation Required message from the serving RNC and determines that the call shall 
be handed over to the Target MSC Server, it shall send the GCR of the call, the LCLS -Negotiation Request IE and the 
LCLS -Configuration-Preference IE to the Target MSC Server in a MAP Prepare-Handover_Request message. 

8.2.3.1 .2.2 Handover Request Acknowledge 

When MSC-1 Server receives the MAP Prepare_Handover_Response including Handover_Request_Acknowledgement 
message with a LCLS -BSS -Status IE the Anchor MSC-1 Server configures the bearer terminations in MGW-1 and 
sends the GCR IE, the LCLS -Negotiation Request IE and the LCLS -Configuration-Preference IE to the target MSC- 
Server. 
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8.2.3.1 .2.3 Bearer establishment between MGW-1 and Target MGW 

The handling of the bearer establishment between MGW-1 and Target MGW is as described in sub-clause 6.1 for a 
Basic Mobile Originating Call. The MSC server shall also use the Change Flow Direction procedure to request the 
MGW-1 to set the Handover Device to the initial state. 

8.2.3.1 .2.4 MGW Flow Direction Control 

In accordance with the normal handover case the MGW-1 isolates the termination towards the Target MGW (T2) from 
the termination to the RNC(Ts) and configures the Anchor termination (Ti) one-way DL towards the Target MGW 
termination (T2). Termination to the RNC (Ts) is both- way connected to Anchor termination (Ti) since it is also 
receiving UL user data from termination to the RNC (Ts). 

8.2.3.1 .2.5 Relocation Command/Handover Detect 

The MSC-1 Server uses the Change Flow Direction procedure to requests the MGW-1 to set the Handover Device to 
intermediate state. 

8.2.3.1 .2.6 Handover Complete 

When the MSC-1 Server receives the Handover Complete message, it releases the related lu-interface connection 
towards RNC. The MSC-1 Server also requests MGW-1 to set the Handover Device to its final state by removing the 
bearer termination towards the RNC. 

The MSC-1 server shall send to the adjacent call node the LCLS -Status-Update message with the LCLS-Status IE 
indicating that LCLS is established. 

8.2.3.1 .3 Target MSC Server / Target MGW 

8.2.3.1 .3.1 Prepare Handover Request message and MGW selection 

The Target MSC server selects the Target MGW when it receives MAP Prepare Handover Request message. The 
Target MSC server sends the Handover Request message to the Target BSS as for the normal case but shall include the 
GCR IE, the LCLS -Configuration IE and the LCLS-Connection-Status-Control IE set to "Connect". 

8.2.3.1 .3.2 Handover Request Acknowledge 

If the Target BSS supports the LCLS feature it shall include the LCLS -BSS -Status IE in the Handover Request 
Acknowledge message in order to inform the Target MSC Server that the BSS supports the LCLS feature. The Target 
MSC Server sends the same information in the MAP Prepare Handover Response message to the MSC-1 Server. 

8.2.3.1 .3.3 Bearer establishment towards Target BSS 

When the Target MSC Server has selected the Target MGW it requests the Target MGW to seize a TDM circuit if 
AoTDM using the Reserve Circuit procedure, or an IP termination if AoIP using the reserve Connection Point 
procedure as for the normal handover procedure. The Target MSC Server sends the Handover Request message to the 
Target BSS containing the CIC for AoTDM or the IP addresses and UDP ports received from the target MGW if AoIP. 

8.2.3.1 .3.4 Bearer establishment between MGW-1 and Target MGW 

The handling of the bearer establishment between MGW-1 and Target MGW is as described for basic mobile 
terminating call in sub-clause 6.2. 

8.2.3.1 .3.5 Handover Complete 

When LCLS has been established during the handover procedure, the target BSS informs the target MSC-Server that 
the call has been locally switched in the Handover Complete message. 

NOTE: The target BSS will send LCLS -Notification message to the MSC at the other call leg indicating the call 
is locally switched. 
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8.2.3.1.4 



Example of Inter-MSC UMTS to GSM Handover that establishes Local Switching 



8.2.3.1.4.1 



Connection Model 



Figure 8.2.3.1.4.1.1 shows the network model for the Basic Inter-MSC UMTS to GSM handover when LCLS is 
estabHshed as a result of the handover. The dashed line in green represents call control signalling and the dashed line in 
blue represents the user plane connection path via the core network, which should be used if LCLS is not established or 
after LCLS is broken. The non-dotted lines represent the bearer carrying real user plane data. In MGW-1 the bearer 
termination Ts is used for the bearer towards RNC, bearer termination Ti is used for the bearer towards the 
succeeding/preceding MOW, that is MGW-2 and bearer termination T2 is used towards the Target MGW. In MGW-2 
the bearer termination T4 is used for the bearer towards BSS-2 and bearer termination T3 is used for the bearer towards 
MGW-1. In Target-MGW the bearer termination Tt is used towards the Target-BSS and bearer termination T5 is used 
towards MGW-1. 

In this example scenario the Handover Device is located in MGW-1 selected for the call establishment by the MSC-1 
server, which controls the call and mobility management. 

User plane link which transmits real user plane data within BSS and to UE 
User plane link which transmits real user plane data through the CN and to UE 
User plane link path through CN, connected 
Control plane link which transmits signalling 
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Connection Model 2: During Handover, T2 is isolated from Is, Ti is one-way connected to T2 
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Connection Model 3: After Handover, LCLS is established and both call legs are in Target BSS 

(=BSS-2) 



8.2.3.1.4.2 



Figure 8.2.3.1.4.1.1 : Basic Inter-MSC UMTS to GSM Handover (network model) 

Basic Sequence for Inter-MSC UMTS to GSM Handover that establishes Local 
Switching 



Figures 8.2.3.1.4.2.1 and 8.2.3.1.4.2.2 show the message sequence example for the Basic Inter-MSC UMTS to GSM 
Handover shown in the corresponding network model Figure 8.2.3.1.4.1.1. The Handover Device is located in MGW-1 
selected for the call establishment by the MSC-1 server, which controls the call and the mobility management. The 
description is based on 3GPP TS 23.009 [9], 3GPP TS 23.205 [2] and 3GPP TS 23.231 [3]. 
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Figure 8.2.3.1.4.2.1 : Initial phase of Inter-MSC UMTS to GSM Handover establishing Local Switching 

1. lu Relocation Required Request is received from RNC requesting an inter-MSC handover. The call is 
currently not locally switched. 

2. The MSC-1 server determines that inter-MSC handover is required and sends the MAP Prepare-Handover 
Request message to target MSC-Server which includes LCLS Negotiation and GCR. 

3a, b. The Target-MSC-Server requests the target MGW to reserve circuit or Connection Point towards the Target- 
BSS 

4. The Target MSC-Server sends Handover Request message to the Target BSS with GCR, the LCLS- 
Configuration IE and the LCLS-Connection-Status-Control IE indicating "connect" to through-connect the 
local call. 

5. Target BSS performs call leg correlation with GCR to find if another call leg is active with same GCR. The 
BSS reports in Handover Request Acknowledge message that the local call was found but LCLS is not yet 
established. 

5a. The BSS-2 notifies MSC-2 server the LCLS status is changed by sending the LCLS_ Notification message 
with the LCLS-BSS-Status IE set to "Call not yet locally switched". 
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5b. If the call has been answered and MSC-2 server permits LCLS to be connected, then the MSC-2 server sends 
to the BSS-2 the LCLS_Connect_Control message with the LCLS-Connection-Status-Control IE set to 
"connect". 

5c. The BSS-2 returns the LCLS_Connect_Control_ACK message with the LCLS -ESS -Status IE set to "Call not 
yet locally switched" . 

6a, b. (These signalling steps are only applicable to AoIP.) When the Target MSC-Server receives the BSSMAP 

Handover Request- Ack message, it sends the BSC-B IP address and UDP Port number to the MGW-B using 
the Configure RTP Connection Point procedure. 

7. The Target MSC-Server sends the MAP Prepare Handover Response message to MSC-1 server. 

8a, b. In accordance with normal handover the MSC-1 server requests MGW-1 to isolate the termination towards 
Target MGW (T2) from the termination to the Serving BSS-1 (Ts) and to configure the Anchor termination 
(Ti) one-way DL towards the Target MGW termination (T2). 

9. MSC-Server 1 sends I AM (Initial Address Message) to Target MSC-Server including GCR and configures 
the LCLS-Negotiation IE. 

NOTE 1: Corresponding SIP-I signalling is specified in 3GPP TS 23.231 [3]. 

NOTE 2: The LCLS-Negotiation IE in step 9 can be different from LCLS Negotiation IE in step 2, because 
step 9 is BICC signalling and the IE value can be changed by intermediate MSC-Servers. 

10a, b. Target MSC-Server reserves bearer connection T5 towards MGW-1. 

11. After Target MGW has replied with the bearer address and the binding reference (Step 10b), the Target 
MSC-Server returns APM with selected codec plus LCLS-Negotiation IE. 

12. Target MSC-Server sends ACM (Address Complete Message). Target MSC-Server awaits the capturing of 
the UE-1 on the radio path when the ACM is sent and MSC-1 server initiates the handover execution when 
receiving ACM. 
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Figure 8.2.3.1.4.2.2: Complet on phase of Inter-MSC UMTS to GSM Handover establishing Loca 

Switching 

13-18. When the local switching has been established during the handover procedure, the target BSS shall inform 
the target MSC-Server that the call has been locally switched in HANDOVER COMPLETE, and the target 
BSS shall also send a new message LCLS -Notification with LCLS-BSS-Status IE to inform the MSC-2 
server that the local switching has been established. In steps 16a and 16b the MSC-1 server configures 
MGW-1 for the completion of the handover. 

19. A-HO-DETECT/COMPLETE when received is included in the MAP-Send-End-Signal request and send 
back to the MSC-1 server. 

20. Target MSC-Server sends ANSWER when A-HO-DETECT/COMPLETE is received. 
21a, b. MSC-1 Server releases the call leg in RNC. 

22a, b. MSC-1 server releases the bearer termination towards RNC. 

23. Target MSC-Server informs the MSC-1 server about the LCLS Status. 

24. MSC-1 server (Anchor MSC-Server) sends LCLS -Status-Update message to the far end MSC-2 server. 

NOTE 3: When BICC is used as the call control protocol the APM message is sent. When SIP-I is used the 
INFO request with the encapsulated APM message is sent. 

25. Local switching is established in the BSS. 
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8.2.3.2 Inter-MSC UMTS to GSM Handover that does not establish Local Switching 

Inter-MSC UMTS to GSM Handover that does not establish Local Switching follows the procedures in 8.2.3.1. The 
differences are: 

- in the step 17, the target BSS informs target MSC that the call is not locally switched in the Handover Complete. 

- steps 5a, 5b, 5c 18, step 23, step 24 and step 25 are not triggered. 

8.3 GSM to UMTS 

8.3.1 Intra-MSC GSM to UMTS Relocation 

8.3.1.1 General 

When a call is locally switched through the BSS and an intra-MSC GSM to UMTS handover occurs, the LCLS shall be 
broken and the user plane shall be connected via the core network. The Intra-MSC GSM to UMTS relocation procedure 
specified in 3GPP TS 23.205 [2] and 3GPP TS 23.231 [3] shall be followed. The following clauses describe the 
additional requirements for intra-MSC GSM to UMTS handovers of LCLS related calls. 

To this end the BSS which is in local switch which is serving the user equipment which is not moving to the RNC 
bicasts user data UL to the core network so that immediately the user equipment which is moving is attached to the 
RNC it can receive DL data from the core network. 

During a Locally Switched (intra-BSS) Connection when no bicasting occurs there is no data transmission through the 
core network. In this release the use plane is kept active and therefore does not need to be re-activated when the LCLS 
is broken due to GSM to UMTS handover out of LCLS. 

8.3.1 .2 Handover Required 

When the MSC server receives the Handover Required message from the serving BSS, it requests the MGW to provide 
a binding reference and a bearer address using the Prepare Bearer procedure. The MSC server shall use the Change 
Flow Direction procedure to request the MGW to set the Handover Device to the initial state, see sub-clause 8.4.1.1.3. 

8.3.1 .3 lu Relocation Request Acknowledge 

Upon receipt of the Relocation Request Acknowledge message, the MSC Server shall send to the adjacent call node the 
LCLS -Status-Change-Request message to indicate "LCLS Disconnection-Preparation-for handover". 

If the far end MSC server receives the LCLS-Status-Change-Request message indicating LCLS Disconnection 
preparation-for-handover it shall send to the BSS the LCLS_Connect_Control message with the LCLS -Connection- 
Status-Control IE indicating "BicastatHandover". When the LCLS_Connect_Control acknowledge message is received 
from the BSS, the far end MSC server shall return the LCLS Status Change Request Acknowledge message indicating 
"LCLS Disconnection-Preparation-for-handover" and a Result code indicating LCLS Status Change Request accepted. 

8.3.1 .4 Handover Command/lu Relocation Detect 

When the MSC server sends the Handover Command message or alternatively if it receives the Relocation Detect 
message, if the MSC server followed the MGW control procedures for a non-LCLS call and kept the Termination to the 
Serving BSS connected then it shall use the Change Flow Direction procedure to requests the MGW to set the Handover 
Device to intermediate state. However if the MSC server isolated Ts and set Tt to bothway through-connected then no 
MGW control procedure is required at this point. 

When the Handover Command message from the CN is received by the BSS, the BSS should start bi-casting the UL 
user plane data to the CN at the other call leg before sending Handover Command message to the MS, if the BSS did 
not receive an explicit indication on the other call leg to start bi-casting. 
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8.3.1.5 



lu Relocation Complete 



When the MSC server receives the lu Relocation Complete message, it releases the A-interface line towards the serving 
BSS. The MSC server also requests the MGW to set the Handover Device to its final state by removing the bearer 
termination (Ts) towards the serving BSS. 

The MSC server shall send to the adjacent call node the LCLS -Status-Update message with the LCLS-Status IE 
indicating the LCLS is disconnected. 

When the serving BSS receives Clear Command it shall release any local switch path. The serving BSS shall inform the 
far end MSC server that LCLS is broken with the LCLS -Notification message. 

NOTE: The LCLS_Notification message does not need to be sent to the Anchor MSC Server since the Clear 
Complete message received from the serving BSS also means that LCLS is disconnected. 



8.3.1.6 



Example 



8.3.1.6.1 



Connection Model 



Figure 8.3.L6.L1 shows the network model for Intra-MSC GSM to UMTS Handover, where the call leg pertinent to the 
UE-1 is handed over from the serving BSS-1 to the Target RNC. BSS-1 is the same as BSS-2 when LCLS is established 
for the call. The bearer termination T2 is used for the bearer towards BSS-2, which is not affected by this handover. 
Bearer termination Ts is used for the bearer towards BSS-1 and the bearer terminations Ti and Ta are used for the 
bearer towards the succeeding/preceding MGW. Bearer termination Tt is for the bearer termination towards the Target 
RNC. The colours and line types used in the figure are defined differently from 3GPP TS 23.205 [2] to indicate LCLS 
specific issues. 

^^^^ User plane link which transmits real user plane data within the BSS and to UEs 

^^^^ User plane link which transmits real user plane data through the CN and to UEs 

• • • User plane path through the CN, connected 

• • • Control plane link which transmits signalling 
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Connection Model 1 : The call is locally switched 
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Connection Model 2: MGW-1 is both-way connected between Ta and Tt, Ts is isolated; BSS-2 starts 

to bicast data UL 
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During Handover 
Ts = Serving 
Ta= Anchor 
Tt = Target 



Connection Model 3: UE has moved to Target RNC but lu Relocation Detect has not yet been 

received by MSC-S-1 
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UE-1 




'j^y^L 



After Handover 
Ta= Anchor 
Tt = Target 

Connection Model 4: LCLS is released in BSS-2, old serving Termination Ts is removed 
Figure 8.3.1.6.1.1 : Network model for Intra-MSC GSM to UMTS Handover that breaks LCLS 

8.3.1 .6.2 Basic Sequence for GSM to UMTS Handover that breaks Local Switching 

Figure 8.3.1.6.2.1 shows the signalling flow for GSM to UMTS handover that breaks Local Switching. 
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Figure 8.3.1.6.2.1 : Intra-MSC GSM to UMTS Handover that terminates Local Switching 

The Handover Required message is received from BSS-1 requesting an intra-MSC GSM to UMTS handover. 
The call is currently locally switched so the MSC-1 server can know that the GSM to UMTS handover at one 
end will break local switch (the local switch is not broken in the serving BSS (BSS-1) until the UE-1 has 
moved from BSS-1 and the MSC-1 server has sent the Clear Command message to the BSS-1). 

In this example the Anchor MSC-1 server requests from its MGW-1 the seizure of the bearer termination Tt 
towards the Target RNC and through-connects it bothway to Ta. Additionally it isolates the old serving 
Termination Ts. This makes the GSM to UMTS handover more efficient than current non-LCLS GSM to 
UMTS handovers as immediately when the UE-1 is handed over to the target RNC it will be able to send UL 
user data to the UE-2. 

NOTE 1 : This flow shows the termination to the Target RNC as always connected bothway. This is a change 
to the existing call handling which would normally connect the termination as one-way and then 
change to bothway after receiving the lu Relocation Detect message. However the termination 
does not need to be connected one-way and will in fact make the break in speech worse since UL 
data cannot be sent from the UE-1 until the MGW topology is modified, also it saves the 
additional intermediate H.248 modification step. 

Anchor MSC-1 server sends the lu Relocation Request message to the target RNC. 

The target RNC returns the lu Relocation Request Acknowledge message. 
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5. Anchor MSC-1 server shall send the LCLS-Status-Change-Request message to the succeeding MSC server 
asking it to prepare for LCLS disconnection due to handover to trigger the far end MSC-2 server to send the 
LCLS-Connect-Control message to BSS-2. 

NOTE 2: When BICC is used as the call control protocol the APM message is sent. When SIP-I is used the 
INFO request with the encapsulated APM message is sent. 

5a. The far end MSC-2 server requests the BSS-2 to start sending data UL with the LCLS_Connect_Control 

message and the LCLS-Connection-Status-Control IE indicating "BicastatHandover", see Figure 8.3.1.6.1.1 
Connection Model 2. This triggers the BSS-1 to bicast the user plane data in the same way as the Access 
MGW-1 would be doing in a non-LCLS inter-BSS handover. At this point the BSS-1 shall send any DL data 
it receives directly to the served UE. Since the BSS-1 cannot receive DL data at the same time as it receives 
local data (Ts is isolated) this will minimise the break in user plane data even more than for existing non- 
LCLS handover. 

NOTE 3: The Serving BSS-1 shall forward the user plane data from the UE-1 to the UE-2 while the UE-1 is 
served by the BSS-1. The UL user plane data are bi-cast to both MGW2 and local path by the 
BSS-2. The MGW-2 transmits the user plane data to the MGW-1, and the MGW-1 will transmit 
the user plane data to the target RNC. When the UE-1 leaves the serving BSS-1 and begins 
sending UL data from the Target RNC, that data will then be received via the A-interface leg at the 
serving BSS-2. 

5b. BSS-2 sends the LCLS_Connect_Control_Ack message with the LCLS -BSS -Status IE set to "the call is 
locally switched with requested LCLS configuration" . 

6. Anchor MSC-1 server triggers the Handover Command message. When the UE-1 moves to the Target RNC 
in this example it can immediately send UL data through the CN to the UE-2 and also can receive DL data 
from the UE-2 via the CN since the MGW-1 topology for Ta, Tt is already both way connected. This is a 
change from the current non-LCLS solution but is more efficient since the non-LCLS solution needs to set 
this to one-way DL only until it receives lu Relocation Detect message. 

7. MSC-2 Server sends LCLS-Status-Change-Request- Acknowledgement. 

8. UE-1 is detected at the target RNC. BSS-l/BSS-2 may continue to send the user plane data locally until the 
Clear Command message is received. 

9. When the MSC-1 Server receives the lu Relocation Complete message MSC-1 Server knows that the call is 
not possible to be locally switched. 

10. MSC-1 server requests the old serving BSS-1 to clear the old call leg. BSS-1 stops sending locally the user 
data from UE-1, LCLS is broken. 

11. Serving BSS-2 informs the MSC-2 server that LCLS is broken via LCLS_Notification message. 

12. Clearing of the old call leg to the Serving BSS-1 is completed. 

13. The termination Ts to the old serving BSS-1 is removed from the Access MGW-1. 

14. Anchor MSC-1 server informs succeeding CN nodes that LCLS is disconnected. 

NOTE 4: When BICC is used as the call control protocol the APM message is sent. When SIP-I is used the 
INFO request with the encapsulated APM message is sent. 

8.3.2 Inter-MSC GSM to UMTS Relocation 
8.3.2.1 General 

When a call is locally switched through the BSS and an inter-MSC GSM to UMTS handover occurs the LCLS shall be 
broken and the user plane shall be connected through the core network. The Inter-MSC GSM to UMTS handover 
procedures specified in 3GPP TS 23.009 [9], 3GPP TS 23.205 [2] and 3GPP TS 23.231 [3] shall be followed. The 
following clauses describe the additional requirements for inter-MSC GSM to UMTS handovers of LCLS related calls. 
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8.3.2.2 MSC-1 / MGW-1 

8.3.2.2.1 Handover Required 

When MSC-1 Server receives the Handover Required message from the serving BSS and determines that the call shall 
be handed over to the Target MSC Server, it shall send the GCR of the call, the LCLS -Negotiation Request IE and the 
LCLS -Configuration-Preference IE to the Target MSC Server in a MAP Prepare-Handover_Request message. 

8.3.2.2.2 lu Relocation Request Acknowledge 

Upon receipt of the MAP Prepare-Handover-Response including lu Relocation Ack message, the MSC-1 Server shall 
send to the adjacent call node the LCLS-Status-Change-Request message to indicate "LCLS Disconnection-Preparation- 
for handover" . 

If the far end MSC server receives the LCLS-Status-Change-Request message indicating LCLS Disconnection 
preparation-for-handover it shall send to the BSS the LCLS_Connect_Control message with the LCLS -Connection- 
Status-Control IE indicating "BicastatHandover". When the LCLS_Connect_Control acknowledge message is received 
from the BSS, the far end MSC server shall return the LCLS Status Change Request Acknowledge message indicating 
"LCLS Disconnection-Preparation-for-handover" and a Result code indicating LCLS Status Change Request accepted. 

8.3.2.2.3 Bearer establishment between MGW-1 and Target MGW 

The handling of the bearer establishment between MGW-1 and Target MGW is as described in sub-clause 6.1 for a 
Basic Mobile Originating Call. The MSC server shall also use the Change Flow Direction procedure to request the 
MGW-1 to set the Handover Device to the initial state. 

8.3.2.2.4 MGW Flow Direction Control 

The MSC Server may perform the MGW Flow Direction Control for GSM to UMTS Relocation as described in sub- 
clause 8.4.2.1.2.4. 

8.3.2.2.5 Handover Gommand/lu Relocation Detect 

When the MSC-1 server sends the Handover Command message or alternatively, if it receives the lu Relocation detect 
message inside a MAP Process- Access-Signalling request, the MSC-1 server shall follow the procedures described in 
sub-clause 8.4.2.1.2.5. 

8.3.2.2.6 lu Relocation Complete 

When the MSC-1 server receives the lu Relocation Complete message inside a MAP Send-End-Signalling Request and 
an ANSWER message including the LCLS status set to LCLS disconnected, it releases the A-interface line towards the 
serving BSS. The MSC-1 server also requests the MGW-1 to set the Handover Device to its final state by removing the 
bearer termination (Ts) towards the serving BSS. 

The MSC-1 server shall send to the adjacent call node the LCLS -Status-Update message with the LCLS-Status IE 
indicating the LCLS is disconnected. 

When the serving BSS receives Clear Command it shall release any local switch path. The serving BSS shall inform the 
far end MSC server that LCLS is broken with the LCLS -Notification message. 

NOTE: The LCLS_Notification message does not need to be sent to the Anchor MSC Server since the Clear 
Complete message received from the serving BSS also means LCLS is disconnected. 

8.3.2.3 Target MSC Server / Target MGW 

8.3.2.3.1 Prepare Handover Request message and MGW selection 

The Target MSC server selects the Target MGW when it receives Prepare Handover Request message. The Target MSC 
server sends the lu Relocation Request message to the Target RNC as for the normal case. 
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8.3.2.3.2 Bearer establishment towards Target RNC 

The procedure specified in 3GPP TS 23.205 [2] sub-clause 8.3.2.2 shall be used. 

8.3.2.3.3 Bearer establishment between MGW-1 and Target MGW 

The handling of the bearer establishment between MGW-1 and Target MGW is as described for basic mobile 
terminating call in sub-clause 6.2. 



8.3.2.4 



Example of Inter-MSC GSM to UMTS Relocation 



8.3.2.4.1 



Connection Model 



Figure 8.4.2.1.4.1.1 shows the network model for the Inter-MSC GSM to GSM Handover, where call leg UE-1 is 
handed over from BSS-1 to the Target RNC. BSS-1 is the same as BSS-2 when LCLS is established for the call. The 
BSS-1 is served by the MSC-Server 1, the Target RNC is served by the Target MSC-Server, and MSC-Server 1 is not 
the same as Target MSC-Server. The bearer termination T2 in MGW-2 is used for the bearer towards BSS-2, which is 
not affected by this handover. Bearer termination Ts in MGW-1 is used for the bearer towards BSS-1 and the bearer 
terminations Ta and T3 in MGW-1, Ti in MGW-2 and T4 in Target-MGW are used for the bearer towards the 
succeeding/preceding MGW. Bearer termination Tt in Target-MGW is for the bearer termination towards the Target 
RNC. 
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Connection Model 1 : Before handover, Local Switching is established 
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Connection Model 3: UE-1 not yet detected in Target RNC, BSS-2 bicasts user plane data UL 
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Connection Model 5: MSC-1 instructed MGW-1 to reroute the user plane, Ta is both-way connected to 
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Connection Model 6: Handover completed, Ts termination was removed 
Figure 8.3.2.4.1.1 : Inter-MSC GSM to UMTS Relocation Connection Model when user plane active 



8.3.2.4.2 



Basic Sequence for Inter-MSC handover that breaks Local Switching 



Figures 8.3.2.4.2.1 and 8.3.2.4.2.2 show the message sequence example for the basic Inter-MSC GSM to GSM 
Handover shown in the corresponding network model Figure 8.3.2.4.1.1. The Handover Device is located in the MGW- 
1 selected for the call establishment by the MSC-1 Server, which controls the call and the mobility management. The 
description is based on 3GPP TS 23.009 [9], 3GPP TS 23.205 [2] and 3GPP TS 23.231 [3]. 
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Figure 8.3.2.4.2.1: Inter-MSC GSM to UMTS Relocation that breaks Local Switching when user plane 

active, initial phase 

1. The Handover Required message is received from BSS-1 requesting an inter-MSC GSM to UMTS handover. 
The call is currently locally switched and the MSC-1 server knows that the Inter-MSC GSM to UMTS 
relocation at one end will break LCLS (the local switch is not broken in the serving BSS (BSS-1) until UE-l 
has moved out of the BSS-1 and the MSC-1 server sends the Clear Command message to BSS-1). 

2. The MSC-1 Server determines that inter-MSC handover is required and sends MAP-Prepare-Handover 
Request message to target MSC. 

3a, b. The Target MSC-Server requests Target MGW to provide a binding reference and a bearer address using the 
Prepare Bearer procedure when reserving Tt towards the Target RNC. 

4. The Target MSC-Server sends the lu Relocation Request message to Target RNC. 

5. The Target RNC sends the lu Relocation Acknowledge message to Target MSC-Server. 

6. The Target MSC-Server sends the Prepare Handover Response message to the MSC-1 server. 

7. The Anchor MSC-1 server may instruct the far end MSC-2 server to prepare for LCLS disconnection due to 
handover by sending the LCLS-Status-Change-Request message. (If the Anchor MSC-1 server does not 
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instruct the MSC-2 server /BSS-2 to prepare for LCLS disconnection for handover, BSS-2 starts bicasting 
user plane data to the core network after receiving the Handover Command message in Step 15.) 

8a. The far end MSC-2 server requests BSS-2 to start sending data UL with the LCLS_Connect_Control 

message and the LCLS-Connection-Status-Control IE indicating "BicastatHandover", see Figure 8.3.2.4.1.1, 
Connection Model 3. This triggers the BSS-2 to bicast the user plane data in the same way as the Access 
MGW-1 would be doing in a non-LCLS inter-BSS handover. At this point the BSS-1 shall send any DL data 
it receives directly to the served UE. 

NOTE 1: The Serving BSS-1 shall forward the user plane data received locally from UE-1 to UE-2 while the 
UE-1 is served by the BSS-1. BSS-2 bicasts UL user plane data to both MGW2 and local path and 
MGW-2 transmits the user plane data to MGW-1 and MGW-1 transmits the user plane data to the 
Target RNC via the Target MGW. When the UE-1 leaves the serving BSS-1 and begins sending 
UL data to the Target RNC via the Target MGW, that data will then be received via the A- 
interface leg at the serving BSS-2. 

8b. The BSS-2 sends the LCLS_Connect_Control_Ack message with the LCLS -BSS -Status IE set to "the call is 
locally switched with requested LCLS configuration" . 

9a, b. In accordance with normal lu relocation in this example the MSC-1 server requests MGW-1 to isolate the 

termination towards Target MGW (T3) from the termination to the Serving BSS-1 (Ts) and to configure the 
Anchor termination (Ta) one-way DL towards the Target MGW termination (T3). 

10. MSC-2 Server sends LCLS-Status-Change-Request- Acknowledge message. 

11. MSC-1 Server sends lAM (Initial Address Message) to Target MSC-Server including GCR and configures 
the LCLS-Negotiation IE. 

NOTE 2: Corresponding SIP-I signalling is specified in 3GPP TS 23.231 [3]. 

NOTE 3: The MSC-1 Server can send lAM before receiving LCLS-Status-Change-Request- Acknowledge 
message. 

12a, b. Target-MSC-Server reserves bearer connection T4 towards MGW-1. 

13. After Target MGW has replied with the bearer address and the binding reference. Target MSC-Server returns 
APM with selected codec and LCLS-Negotiation IE. 

14. The Target MSC-Server sends ACM (Address Complete Message). Target MSC-Server awaits the capturing 
of the UE-1 on the radio path when the ACM is sent and the Anchor MSC-1 server initiates the lu relocation 
execution when receiving ACM. 
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Figure 8.3.2.4.2.2: Inter-MSC GSM to UMTS Relocation that breaths Local Switching when user p ane 

active, completion phase 

15. MSC-1 server sends Handover Command message to BSS-1. 

16. BSS-1 sends Handover Command message to UE-1. BSS-1 will discard incoming user plane data send to 
UE-1 received from CN. If BSS-2 was not instructed to prepare for LCLS related handover in Step 8a, the 
BSS-2 starts bi-casting UP user plane data generated by UE-2 to local path and A interface and also starts to 
check whether there is incoming DL user plane data from the core network. 

NOTE 4: there is no situation where BSS-2 will receive real DL user plane data from the CN at the same 
time as it receives local data from UE-1 as part of the handover. 

17. UE-1 is detected at Target RNC. But still no UL data can be sent from Target RNC to MGW-1 because Ta- 
T3 is one-way DL only. MGW-1 will continue to transmit DL user plane data to the Target RNC. BSS-2 
continues to bi-cast user plane data to both local path and to the A interface. 

18. Target MSC-Server sends MAP-Process- Access-Signal request message to the MSC-1 server. 

19a, b. The MSC-1 server uses the Change Flow Direction procedure to request the MGW-1 to set the Handover 
Device to intermediate state and TA-T3 to both- way configuration. When BSS-2 finds out there is DL user 
plane data, BSS-2 will transmit the DL user plane data to UE-2. 

20. lu Relocation Complete message is received from Target RNC with LCLS -BSS -status indicating that the call 
cannot be locally switched. 

21. lu-Relocation-Complete message when received is included in the MAP SendEndSignalling Request 
message sent to the MSC-1 server. 
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22. Target MSC-Server sends ANSWER with the LCLS-status when lu-Relocation Complete message is 
received. 

23. MSC-1 server informs BSS-1 to clear the old call leg. 

24. Serving BSS-2 informs MSC-2 server that LCLS is broken via LCLS -Notification message. 

25. MSC-1 server sends LCLS Status Update message with LCLS status "LCLS not connected" to MSC-2 
server. 

NOTE 5: When BICC is used as the call control protocol the APM message is sent. When SIP-I is used the 
INFO request with the encapsulated APM message is sent. 

26. BSS-1 informs MSC-1 server that the resource for the UE-1 has been released and BSS-2 stops bi-casting. 

NOTE 6: There is no need to send LCLS -Notification message from BSS-1 after receiving the Clear 
command since Clear Complete message indicates that LCLS was disconnected. 

27a, b. The MSC-1 server requests MGW-1 to set the Handover Device to its final state by removing the bearer 
termination Ts towards BSC-1 using the Release Termination procedure. 

8.4 GSM to GSM 

8.4.1 Intra-MSC Inter-BSS GSM to GSM Handover 

8.4.1 .1 Intra-MSC Inter-BSS GSM to GSM Handover that breaks Local Switching 

8.4.1.1.1 General 

When a call is locally switched through the BSS and an intra-MSC inter-BSS GSM to GSM handover occurs then the 
LCLS shall be broken and the user plane shall be connected through the core network. The intra-MSC inter BSS GSM 
to GSM handover procedures specified in 3GPP TS 23.205 [2] and 3GPP TS 23.231 [3] shall be followed. The 
following clauses describe the additional requirements for intra-MSC inter BSS GSM to GSM handovers of LCLS 
related calls. 

During a Locally Switched (intra-BSS) Connection when no bicasting occurs there is no data transmission through the 
core network. In this release the use plane is kept active and therefore does not need to be re-activated when the LCLS 
is broken due to inter-BSS handover out of LCLS. 

8.4.1 .1 .2 Handover Required 

When the MSC server receives the Handover Required message from the serving BSS, it requests the MGW to seize a 
TDM circuit if AoTDM or an IP termination if AoIP for the termination to the Target BSS as for the normal handover 
procedure. The MSC server shall use the Change Flow Direction procedure to request the MGW to set the Handover 
Device to the initial state. 

8.4.1 .1 .3 MGW Flow Direction Control 

The MSC Server may perform the MGW Flow Direction Control in the following ways: 

- In accordance with the normal handover case by isolating the termination to the Target BSS (Tt) from the 

termination to the Serving BSS (Ts) and configuring the Anchor termination (Ta) one-way DL to the Target BSS 
(Tt). Termination to the Serving BSS (Ts) is both way connected to Anchor termination (Ta) since it is also 
receiving UL user data from termination to the Serving BSS (Ts). 



Or: 



The MSC server may request the MGW to set termination to Target BSS (Tt) to both way connected to Anchor 
termination (Ta) and isolate termination to Serving BSS (Ts) completely. This improves the user plane switching 
and saves a signalling step to the MGW at Handover Detect message. The MSC server sends the Handover 
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Request message to the Target BSS as for the normal case but shall include the GCR IE, the LCLS- 
Configuration IE and the LCLS-Connection-Status-Control IE set to "Connect". 

8.4.1.1.4 Handover Request Acknowledge 

If the Target BSS supports LCLS feature then it shall include the LCLS -BSS -Status IE in the Handover Request 
Acknowledge message in order to inform the anchor MSC Server that the BSS supports the LCLS feature, and therefore 
the MSC Server shall not act upon the status indicated, i.e. no signalling of LCLS-Status IE through the core network. 

Upon receipt of the Handover Request Acknowledge message the MSC Server shall send to the adjacent call node the 
LCLS -Status-Change-Request message to indicate "LCLS Disconnection-Preparation-for handover". 

If the far end MSC server receives the LCLS-Status-Change-Request message indicating LCLS Disconnection 
preparation-for-handover it shall send to the BSS the LCLS_Connect_Control message with the LCLS -Connection- 
Status-Control IE indicating "BicastatHandover". When the LCLS_Connect_Control acknowledge message is received 
from the BSS, the far end MSC server shall return the LCLS Status Change Request Acknowledge message indicating 
"LCLS Disconnection-Preparation-for-handover" and a Result code indicating LCLS Status Change Request accepted. 

8.4.1 .1 .5 Handover Command/Handover Detect 

When the MSC server sends the Handover Command message or alternatively if it receives the Handover Detect 
message, if the MSC server followed the MGW control procedures for a non-LCLS call and kept the Termination to the 
Serving BSS connected then it shall use the Change Flow Direction procedure to requests the MGW to set the Handover 
Device to intermediate state however if the MSC server isolated Ts and set Tt to both way through-connected then no 
MGW control procedure is required at this point. 

When the Handover Command message from the CN is received by the BSS, the BSS should start bi-casting the UL 
user plane data to the CN at the other call leg before sending Handover Command message to the MS, if the BSS did 
not receive an explicit indication on the other call leg to start bi-casting. 

8.4.1 .1 .6 Handover Complete 

When the MSC server receives the Handover Complete message, it releases the A-interface line towards the serving 
BSS. The MSC server also requests the MGW to set the Handover Device to its final state by removing the bearer 
termination (Ts) towards the serving BSS. 

The MSC server shall send to the adjacent call node the LCLS -Status-Update message with the LCLS-Status IE 
indicating the LCLS disconnection. 

When the serving BSS receives Clear Command it shall release any local switch path. The serving BSS shall inform the 
far end MSC server that LCLS is broken with the LCLS_Notification message. 

NOTE: The LCLS_Notification message does not need to be sent to the Anchor MSC Server since the Clear 
Command message received from the serving BSS also means LCLS is disconnected. 

8.4.1.1.7 Example 

8.4.1 .1 .7.1 Connection Model 

Figure 8.4.1.1.7.1.1 shows the network model for the Intra-MSC Inter-BSS GSM to GSM Handover, where the call leg 
pertinent to the UE-1 is handed over from the serving BSS-1 to the Target BSS. BSS-1 is the same as BSS-2 when 
LCLS is established for the call. The bearer termination T2 is used for the bearer towards BSS-2, which is not affected 
by this handover. Bearer termination Ts is used for the bearer towards BSS-1 and the bearer terminations Tl and Ta are 
used for the bearer towards the succeeding/preceding MGW. Bearer termination Tt is for the bearer termination towards 
the Target BSS. The colours and line types used in the figure are defined differently from 3 GPP TS 23.205 [2] to 
indicate LCLS specific issues. 
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User plane link which transmits real user plane data within the BSS and to UEs 
User plane link which transmits real user plane data through the CN and to UEs 
User plane path through the CN, connected 
Control plane link which transmits signalling 
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Connection Model 1 : The call is locally switched 
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Connection Model 2: MGW-1 is both-way connected between Ta and Tt, Ts is isolated; BSS-2 starts 

to bicast data UL 
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Control Signalling 
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Connection Model 3: UE has moved to Target BSS but HO Detect has not yet been received by MSC- 
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After Handover 
Ta = Anchor 
Tt = Target 

Connection Model 4: LCLS is released in BSS-2, old serving Termination Ts is removed 
Figure 8.4.1.1.7.1.1: Intra-MSC Inter-BSS Handover Connection Model that breaks LCLS 
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8.4.1.1.7.2 



Basic Sequence for Inter-BSS Handover that breaks Local Switching 
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Figure 8.4.1.1.7.2.1 : Intra-MSC Inter-BSS Handover that breaks Local Switching 

1. The Handover Required message is received from the BSS-1 requesting an inter-BSS handover. The call is 
currently locally switched so the MSC-1 server can know that the inter-BSS handover at one end will break 
local switch (the local switch is not broken in the serving BSS (BSS-1) until the UE-1 has moved out of the 
BSS-1 and the MSC-1 server sends the Clear Command message). 

2. In this example the Anchor MSC-1 server requests from its MGW-1 the seizure of the bearer termination Tt 
towards the Target BSS and through-connects it bothway to Ta. Additionally it isolates the old serving 
Termination Ts. This makes the handover much more efficient than even current non-LCLS handover as 
immediately the UE-1 moves into the new target BSS it will be able to send UL user data to the UE-2. 

NOTE 1: This flow shows the termination to the Target BSS as always connected bothway. This is a change 
to the existing call handling which would normally connect the termination as one-way and then 
change to bothway after receiving the Handover Detect message. However the termination does 
not need to be connected one-way and will in fact make the break in speech worse since UL data 
cannot be sent from the UE-1 until the MGW topology is modified, also it saves the additional 
intermediate H.248 modification step. 
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3. The Anchor MSC-1 server sends the Handover Request message to the Target BSS with the GCR IE, the 
LCLS -Configuration IE and the LCLS -Connection-Status-Control IE indicating "connect" to through- 
connect the local call. 

4. The Target BSS returns the Handover Request Acknowledge message and also indicates that call is not 
possible to be locally switched. 

5. The Anchor MSC-1 server sends the change in LCLS to the succeeding MSC server and the Anchor MSC-1 
server asks it to prepare for the LCLS disconnection for Handover to trigger sending of the LCLS-Connect- 
Control message at the far end MSC-2 server. 

NOTE 2: When BICC is used as the call control protocol the APM message is sent. When SIP-I is used the 
INFO request with the encapsulated APM message is sent. 

5a. The far end MSC-2 server requests the BSS-2 to start sending data UL with the LCLS_Connect_Control 

message and the LCLS-Connection-Status-Control IE indicating "BicastatHandover", see Figure 8.4.1.7.1.1 
Connection Model 2. This triggers the BSS-2 to bicast the user plane data in the same way as the Access 
MGW-1 would be doing in a non-LCLS inter-BSS handover. At this point the BSS-2 shall send any DL data 
it receives directly to the served UE. Since the BSS-2 cannot receive DL data at the same time as it receives 
local data (Ts is isolated) this will minimise the break in user plane data even more than for existing non- 
LCLS handover. 

NOTE 3: The Serving BSS-1 shall forward the user plane data from the UE-1 to the UE-2 while the UE-1 is 
served by the BSS-1. The UL user plane data from UE-2 are bi-cast to both MGW2 and local path 
by the BSS-2. The MGW-2 transmits the user plane data to the MGW-1, and the MGW-1 will 
transmit the user plane data to the target BSS. When the UE-1 leaves the serving BSS-1 and begins 
sending UL data from the Target BSS, that data will then be received via the A-interface leg at the 
serving BSS-2. 

NOTE 4: Possible bicasting may have been activated earlier when LCLS was established in the BSS-1 

/BSS-2 (not shown in the figure 8.4.1.8.2.1) and was indicated with the LCLS -Configuration IE in 
step 3 and applies to both call legs. If LCLS bicasting was not activated the LCLS -Configuration 
value is "Connect" (i.e. no bicasting) in step 3, but the value of the LCLS-Connection-Status- 
Control in step 5 is "BicastatHandover", which applies only for this call leg. 

5b. The BSS-2 sends the LCLS_Connect_Control_Ack message with the LCLS -BSS -Status IE set to "the call is 
locally switched with requested LCLS configuration" . 

6. The Anchor MSC-1 server triggers the Handover Command message. When the UE-1 moves to the Target 
BSS in this example it can immediately send UL data through the CN to the UE-2 and also can receive DL 
data from the UE-2 via the CN since the MGW-1 topology for Ta, Tt is already both way connected. This is a 
change from the current non-LCLS solution but is more efficient since the non-LCLS solution needs to set 
this to one-way DL only until it receives Handover Detect message. 

7. MSC-2 Server sends LCLS-Status-Change-Request- Acknowledgement. 

8. The UE-1 is detected at the target BSS. The BSS-l/BSS-2 may continue to send the user plane data locally 
until the Clear Command message is received. 

9. In the Handover Complete message the Target-BSS indicates to the MSC-1 server in the LCLS -BSS -Status 
IE that the call is not possible to be locally switched. 

10. The MSC-1 server requests the old serving BSS-1 to clear the old call leg. The BSS-1 now stops sending 
local the user data from UE-1, LCLS is finally broken. 

11. The Serving BSS-2 informs the MSC-2 server that LCLS is broken via LCLS_Notification message. 

12. Clearing of the old call leg to the Serving BSS-1 is completed. 

13. The termination Ts to the old serving BSS-1 is removed from the Access MGW-1. 

14. The Anchor MSC-1 server informs succeeding CN nodes that LCLS is finally disconnected. 

NOTE 5: When BICC is used as the call control protocol the APM message is sent. When SIP-I is used the 
INFO request with the encapsulated APM message is sent. 
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LCLS is impossible after an Inter-BSS handover which makes the call not local (as described above). While a handover 
is being performed for one call leg, it is possible that a handover also is started for the other call leg, possibly moving 
both call legs to the same target BSS, thereby creating a local call. The target BSS shall only establish LCLS for a local 
call when both call legs are connected and e.g. any handover process has been successfully completed on both call legs. 

8.4.1 .2 Intra-MSC Inter-BSS GSM to GSM Handovers that establishes Local 

Switching 

8.4.1.2.1 General 

When LCLS is not established for a call and an intra-MSC inter-BSS GSM to GSM handover occurs that makes the call 
local, the call should be locally switched in the BSS. The Intra-MSC inter-BSS GSM to GSM handover procedures 
specified in 3GPP TS 23.009 [9], 3GPP TS 23.205 [2] and 3GPP TS 23.231 [3] shall be followed. The following 
clauses describe the additional requirements for intra-MSC handovers that establish LCLS. 

8.4.1 .2.2 Handover Required 

When the MSC server receives the Handover Required message from the serving BSS, it requests the MGW to seize a 
TDM circuit if AoTDM or an IP termination if AoIP for the termination to the Target BSS as for the normal handover 
procedure. The MSC server shall use the Change Flow Direction procedure to request the MGW to set the Handover 
Device to the initial state. 

8.4.1 .2.3 Bearer establishment towards Target BSS 

When the MSC-Server has selected the Target MGW it requests the Target MGW to seize a TDM circuit if AoTDM 
using the Reserve Circuit procedure, or an IP termination if AoIP using the reserve Connection Point procedure as for 
the normal handover procedure. The MSC-Server sends the Handover Request message to the Target BSS containing 
the CIC for AoTDM or the IP addresses and UDP ports received from the target MGW if AoIP. 

8.4.1 .2.4 MGW Flow Direction Control 

In accordance with the normal handover case the MGW-1 isolates the termination towards the Target BSS (Tt) from the 
termination to the Serving BSS (Ts) and configures the Anchor termination (Ta) one-way DL towards the Target BSS 
termination (Tt). Termination to the Serving BSS (Ts) is both- way connected to Anchor termination (Ta) since it is also 
receiving UL user data from termination to the Serving BSS (Ts). 

8.4.1 .2.5 Handover Request Acknowledge 

If the Target BSS supports the LCLS feature it shall include the LCLS -BSS -Status IE in the Handover Request 
Acknowledge message in order to inform the anchor MSC Server that the BSS supports the LCLS feature. 

The anchor MSC Server shall not act upon the status indicated, i.e. no signalling of LCLS-Status IE through the core 
network. 

8.4.1 .2.6 Handover Command/Handover Detect 

The anchor MSC Server shall use the Change Flow Direction procedure to requests the MGW-1 to set the Handover 
Device to intermediate state. 

8.4.1 .2.7 Handover Complete 

When the MSC-Server receives the Handover Complete message, it releases the A-interface line towards the serving 
BSS. The MSC-Server also requests the MGW to set the Handover Device to its final state by removing the bearer 
termination towards the serving BSS. 

When LCLS has been established during the handover procedure, the target BSS informs the anchor MSC-Server that 
the call has been locally switched in the Handover Complete message. 

The MSC-Server shall send to the adjacent call node the LCLS -Status-Update message with the LCLS-Status IE 
indicating that LCLS was established. 
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8.4.1.2.8 



Example 



8.4.1.2.8.1 



Connection Model 



Figure 8.4.1.2.8.1.1 shows the network model for the Intra-MSC Inter-BSS GSM to GSM Handover, where the call leg 
pertinent to the UE-1 is handed over from the serving BSS-1 to the Target BSS. Target ESS is the same as BSS-2 when 
LCLS is established for the call. The bearer termination T2 is used for the bearer towards BSS-2, which is not affected 
by this handover. Bearer termination Ts is used for the bearer towards BSS-1 and the bearer terminations Ti and Ta are 
used for the bearer towards the succeeding/preceding MGW. Bearer termination Tt is for the bearer termination towards 
the Target BSS. The colours and line types used in the figure are defined differently from 3GPP TS 23.205 [2] to 
indicate LCLS specific issues. 

^^^^ User plane link which transmits real user plane data within the BSS and to UEs 
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• • • User plane path through the ON, connected 
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Connection Model 4: The call is locally switched 
Figure 8.4.1 .2.8.1 .1 : Connection Models for Inter-BSS Handover that establishes Local Switching 



8.4.1.2.8.2 



Basic Sequence for Inter-BSS Handover that establishes Local Switching 



Figures 8.4.1.2.8.2.1 and 8.4.1.2.8.2.2 show the message sequence example for the Basic Intra-MSC GSM to GSM 
Handover shown in the corresponding network model Figure 8.4.1.2.8.1.1. The Handover Device is located in MGW-1 
selected for the call establishment by the MSC-1 server, which controls the call and the mobility management. The 
description is based on 3GPP TS 23.009 [9], 3GPP TS 23.205 [2] and 3GPP TS 23.231 [3]. 
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Figure 8.4.1.2.8.2.1 : Inter-BSS Handover that establishes Local Switching 

Handover Required message is received from BSS-1 requesting an inter-MSC handover. The call is currently 
not locally switched. 

MSC-1 Server determines that an intra-MSC handover is required and checks that LCLS negotiation in the 
core network permitted LCLS. The MSC-1 Server reserves a new Termination for Target BSS and configures 
this as one-way connected to the Anchor Termination (as per existing handover procedures). 

MSC-1 Server sends Handover Request message to target BSS with GCR and instructs the BSS to prepare to 
connect LCLS. The LCLS-Configuration IE can instruct the BSS to bi-cast user plane data, if applicable. 

Target BSS performs call leg correlation with GCR to find if another call leg is active with the same GCR. 
The BSS reports in Handover Request Acknowledge message that the local call was found but LCLS is not 
yet established. 

The BSS-2 notifies MSC-2 server the LCLS status is changed by sending the LCLS_Notification message 
with the LCLS-BSS-Status IE set to "Call not yet locally switched". 

If the call has been answered and MSC-2 server permits LCLS to be connected, then the MSC-2 server sends 
to the BSS-2 the LCLS_Connect_Control message with the LCLS-Connection-Status-Control IE set to 
"connect". 
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4c. The BSS-2 returns the LCLS_Connect_Control_ACK message with the LCLS-BSS -Status IE set to "Call not 
yet locally switched" . 

5a, b. (These signalling steps are only applicable to AoIP.) MSC-1 Server sends the IP address and UDP Port 
number of the Target BSS to MGW-1 using the Configure RTP Connection Point procedure. 

6. MSC-1 Server sends the Handover Command message. 

7. UE-1 gets connected to the Target BSS, which sends Handover Detect. 

8a, b. In accordance with normal handover the MSC-1 Server requests MGW-1 to isolate the termination towards 
Target BSS (Tt) from the termination to the Serving BSS-1 (Ts) and to configure the Anchor termination 
(Ta) one-way DL towards the Target BSS termination (Tt). 

9. Target BSS indicates in the Handover Complete message that the call is locally switched. 

10. BSS-2 sends the LCLS_Notification message to MSC-2 Server with the LCLS-BSS-Status IE set to "call is 
locally switched with requested LCLS configuration" . 

11. MSC-1 Server requests the old serving BSS-1 to clear the old call leg. 

12. Clearing of the old call leg to the Serving BSS-1 is completed. 

13. The termination Ts to the old serving BSS-1 is removed from MGW-1. 

14. MSC-1 Server informs succeeding CN nodes that LCLS is connected. 

NOTE: When BICC is used as the call control protocol the APM message is sent. When SIP-I is used the 
INFO request with the encapsulated APM message is sent. 

LCLS becomes possible after an Inter-BSS handover which makes the call local (as described above). While a handover 
is being performed for one call leg, it is possible that a handover also is started for the other call leg, possibly moving 
that call leg to another BSS and in that case the call does not become local. The target BSS shall only establish LCLS 
for a local call when both call legs are connected and e.g. any handover process has been successfully completed on 
both call legs. 

8.4.2 Inter-MSC GSM to GSM Handover 

8.4.2.1 Inter-MSC GSM to GSM Handover that breaks Local Switching 

8.4.2.1.1 General 

If LCLS is established for a call and an inter-MSC GSM to GSM handover occurs that makes the call not local the 
LCLS shall be broken in the BSS and the user plane data shall be connected through the core network. The Inter-MSC 
GSM to GSM handover procedures specified in 3GPP TS 23.009 [9], 3GPP TS 23.205 [2] and 3GPP TS 23.231 [3] 
shall be followed. The following clauses describe the additional requirements for inter-MSC handovers of LCLS related 
calls. 

8.4.2.1.2 MSC-1 /MGW-1 

8.4.2.1 .2.1 Handover Required 

When MSC-1 Server receives the Handover Required message from the serving BSS and determines that the call shall 
be handed over to the Target MSC Server, it shall send the GCR of the call, the LCLS -Negotiation Request IE and the 
LCLS -Configuration-Preference IE to the Target MSC Server in a MAP Prepare-Handover_Request message. 

8.4.2.1 .2.2 Handover Request Acknowledge 

When MSC-1 Server receives the MAP Prepare_Handover_Response including Handover_Request_Acknowledgement 
message with a LCLS-BSS-Status IE the Anchor MSC-1 Server shall send to the adjacent call node, MSC-2 Server, the 
LCLS -Status-Change Request message containing the LCLS -Status-Change-Request IE to signal the change of LCLS 
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status. In the LCLS -Status-Change-Request IE the MSC-1 server shall indicate "LCLS Disconnection-Preparation-for 
handover" . 

If the MSC-2 Server receives the LCLS -Status-Change Request message with the LCLS -Status-Change-Request IE that 
requires LCLS Disconnection preparation-for-handover it shall send to BSS-2 the LCLS_Connect_Control message 
with the LCLS -Connection-Status-Control IE indicating "BicastatHandover". When the LCLS_Connect_Control 
acknowledge message is received from the BSS-2, the MSC-2 server shall return the LCLS Status Change Request 
Acknowledge message indicating "LCLS Disconnection-Preparation-for-handover" and a Result code indicating LCLS 
Status Change Request accepted. 

8.4.2.1 .2.3 Bearer establishment between MGW-1 and Target MGW 

The handling of the bearer establishment between MGW-1 and Target MGW is as described in sub-clause 6.1 for a 
Basic Mobile Originating Call. The MSC server shall also use the Change Flow Direction procedure to request the 
MGW-1 to set the Handover Device to the initial state. 

8.4.2.1 .2.4 MGW Flow Direction Control 

The MSC Server may perform the MGW Flow Direction Control in the following ways: 

- In accordance with the normal handover case by isolating the termination in MGW-1 towards the Target MGW 
(T2) from the termination to the Serving BSS (Ts) and configuring the Anchor termination (Ta) one-way DL 
towards the Target MGW termination (T2). Termination to the Serving BSS (Ts) is both- way connected to 
Anchor termination (Ta) since it is also receiving UL user data from termination to the Serving BSS (Ts). The 
basic example in sub-clause 8.4.2.1.4 illustrates this type of functionality. 

Or: 

- The MSC-1 Server may request the MGW-1 to set termination towards Target-MGW (T2) to both- way 
connected to Anchor termination (Ta) and isolate termination to Serving BSS (Ts) completely. This improves the 
user plane switching and saves a signalling step to the MGW-1 at Handover Detect message. 

8.4.2.1 .2.5 Handover Command/Handover Detect 

When the MSC-1 server sends the Handover Command message or alternatively if it receives the Handover Detect 
message inside a MAP Process- Access-Signalling request, if the MSC-1 server followed the MGW control procedures 
for a non-LCLS call and kept the Termination to the Serving BSS connected then it shall use the Change Flow 
Direction procedure to requests the MGW-1 to set the Handover Device to intermediate state, however if the MSC 
server- 1 isolated Ts and set T2 to both way then no MGW control procedure is required at this point. 

8.4.2.1 .2.6 Handover Complete 

When the MSC-1 Server receives the Handover Complete message, it releases the A-interface line towards BSS-1. The 
MSC-1 Server also requests MGW-1 to set the Handover Device to its final state by removing the bearer termination 
towards the BSS-1. 

After the MSC-1 Server receives the Answer message including the LCLS-Status set to LCLS feasible but not yet 
locally switched, MSC-1 Server shall send to the adjacent call node the LCLS -Status-Update message with the LCLS- 
Status IE indicating that LCLS is not established. 

8.4.2.1 .3 Target MSC Server / Target MGW 

8.4.2.1 .3.1 Prepare Handover Request message and MGW selection 

The Target MSC server selects the Target MGW when it receives Prepare Handover Request message. The Target MSC 
server sends the Handover Request message to the Target BSS as for the normal case but shall include the GCR IE, the 
LCLS -Configuration IE and the LCLS -Connection-Status-Control IE set to "Connect". 
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8.4.2.1 .3.2 Handover Request Acknowledge 

If the Target BSS supports the LCLS feature it shall include the LCLS-BSS -Status IE in the Handover Request 
Acknowledge message in order to inform the Target MSC Server that the BSS supports the LCLS feature. The Target 
MSC Server sends the same information in the MAP Prepare Handover Response message to the MSC-1 Server. 

8.4.2.1 .3.3 Bearer establishment towards Target BSS 

When the Target MSC Server has selected the Target MGW it requests the Target MGW to seize a TDM circuit if 
AoTDM using the Reserve Circuit procedure, or an IP termination if AoIP using the reserve Connection Point 
procedure as for the normal handover procedure. The Target MSC Server sends the Handover Request message to the 
Target BSS containing the CIC for AoTDM or the IP addresses and UDP ports received from the target MGW if AoIP. 

8.4.2.1 .3.4 Bearer establishment between MGW-1 and Target MGW 

The handling of the bearer establishment between MGW-1 and Target MGW is as described for basic mobile 
terminating call in sub-clause 6.2. 

8.4.2.1 .3.5 LCLS Negotiation in Initial Address message 

If the Target MSC Server receives an Initial Address message that does not include a LCLS -Negotiation Request IE or 
includes a LCLS -Negotiation Request IE set to LCLS is not permitted, the Target MSC Server shall update the 
previously sent LCLS -Configuration by sending a LCLS_CONNECT_CONTROL message to BSS with a LCLS- 
Configuration IE set to LCLS-not allowed and a LCLS_Connection_Status_Control IE set to "do not connect LCLS". 

8.4.2.1 .4 Example of Inter-MSG Handover that breaks Local Switching 

8.4.2.1 .4.1 Connection Model 

Figure 8.4.2.1.4.1.1 shows the network model for the Inter-MSC GSM to GSM Handover, where call leg UE-1 is 
handed over from BSS-1 to the Target BSS. BSS- 1 is the same as BSS-2 when LCLS is established for the call. The 
BSS-1 is served by the MSC-Server 1, the Target BSS is served by the Target MSC-Server, and MSC-Server 1 is not 
the same as Target MSC-Server. The bearer termination Tj in MGW-2 is used for the bearer towards BSS-2, which is 
not affected by this handover. Bearer termination Ts in MGW-1 is used for the bearer towards BSS-1 and the bearer 
terminations Ta and T3 in MGW-1, Ti in MGW-2 and T4 in Target-MGW are used for the bearer towards the 
succeeding/preceding MGW. Bearer termination Tt in Target-MGW is for the bearer termination towards the Target 
BSS. 
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Connection Model 6: Handover completed, Ts termination was removed 
Figure 8.4.2.1.4.1.1 : Inter-MSC Inter-BSS Handover Connection Model when user plane active 



8.4.2.1.4.2 



Basic Sequence for Inter-MSC handover that breaks Local Switching 



Figures 8.4.2.1.4.2.1 and 8.4.2.1.4.2.2 show the message sequence example for the basic Inter-MSC GSM to GSM 
Handover shown in the corresponding network model Figure 8.4.2.1.4.1.1. The Handover Device is located in the 
MGW-1 selected for the call establishment by the MSC-1 Server, which controls the call and the mobility management. 
The description is based on 3GPP TS 23.009 [9], 3GPP TS 23.205 [2] and 3GPP TS 23.231 [3]. 
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Figure 8.4.2.1.4.2.1 : Inter-MSC Handover that breaks LCLS when user plane active, initial phase 

1. The Handover Required message is received from BSSl requesting an inter-MSC handover. The call is 
currently locally switched and the MSC-1 server can know that the Inter-MSC handover at one end will 
break LCLS (the local switch is not broken in the serving BSS (BSS-1) until UE-l has moved out of the 
BSS-1 and the MSC-1 server sends the Clear Command message to BSS-1). 

2. The MSC-1 Server determines that inter-MSC handover is required and sends MAP-Prepare-Handover 
Request to target MSC which includes LCLS Negotiation and GCR IBs. 

3a, b. The Target MSC-Server reserves circuit or Connection Point Tt towards the Target BSS. 

4. The Target MSC-Server sends the Handover Request message to target BSS with the GCR IE, the LCLS- 
Configuration IE and the LCLS-Connection-Status-Control IE indicating "connect" to through-connect the 
local call. 

5. The Target BSS reports in Handover Request Acknowledge message that the call is not possible to be locally 
switched. 
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6a, b. (These signalling steps are only applicable to AoIP) When the Target MSC-Server receives the BSSMAP 
Handover Request- Ack message, it sends the target BSC IP address and UDP Port number to the target 
MGW using the Configure RTP Connection Point procedure. 

7. The Target MSC-Server sends the Prepare Handover Response message to the MSC-1 server. 

8a. The Anchor MSC-1 server instructs the far end MSC-2 server to prepare for LCLS disconnection for 
Handover by sending the LCLS-Status-Change-Request message. 

8b. The far end MSC-2 server requests BSS-2 to start sending data UL with the LCLS_Connect_Control 
message and the LCLS-Connection-Status-Control IE indicating "BicastatHandover", see Figure 
8.4.2.1.4.1.1, Connection Model 3. This triggers the BSS-2 to bicast the user plane data in the same way as 
the Access MGW-1 would be doing in a non-LCLS inter-BSS handover. At this point the BSS-1 shall send 
any DL data it receives directly to the served UE. 

NOTE 1: The Serving BSS-1 shall forward the user plane data received locally from UE-1 to UE-2 while the 
UE-1 is served by the BSS-1. BSS-2 bicasts UL user plane data to both MGW2 and local path and 
MGW-2 transmits the user plane data to MGW-1 and MGW-1 transmits the user plane data to the 
Target BSS via the Target MGW. When the UE-1 leaves the serving BSS-1 and begins sending 
UL data to the Target BSS via the Target MGW, that data will then be received via the A-interface 
leg at the serving BSS-2. 

NOTE 2: Possible bicasting may have been activated earlier when LCLS was established in the BSS-1 

/BSS-2 (not shown here) and was indicated with the LCLS -Configuration IE in step 4 and applies 
to both call legs. If LCLS bicasting was not activated the LCLS -Configuration value is "Connect" 
(i.e. no bicasting) in step 4, but the value of the LCLS-Connection-Status-Control in step 8b is 
"BicastatHandover", which applies only for this call leg. 

8c. The BSS-2 sends the LCLS_Connect_Control_Ack message with the LCLS -BSS -Status IE set to "the call is 
locally switched with requested LCLS configuration" . 

8d. MSC-2 Server sends LCLS-Status-Change-Request- Acknowledge message. 

NOTE 3: Handover sequence is independent of the LCLS-Status-Change-Request- Acknowledge message. 

9a, b. In accordance with normal handover the MSC-1 server requests MGW-1 to isolate the termination towards 
Target MGW (T3) from the termination to the Serving BSS-1 (Ts) and to configure the Anchor termination 
(Ta) one-way DL towards the Target MGW termination (T3). 

10. MSC-Server 1 sends I AM (Initial Address Message) to Target MSC-Server including GCR and configures 
the LCLS-Negotiation IE. 

NOTE 4: Corresponding SIP-I signalling is specified in 3GPP TS 23.231 [3]. 

1 la, b. Target-MSC-Server reserves bearer connection T4 towards MGW-1. 

12. After Target MGW has replied with the bearer address and the binding reference. Target MSC-Server returns 
Bearer and Codec Information (APM) message with selected codec, available codec list and LCLS- 
Negotiation IE. 

13. The Target MSC-Server sends ACM (Address Complete Message). Target MSC-Server awaits the capturing 
of the UE-1 on the radio path when the ACM is sent and the Anchor MSC-1 server initiates the handover 
execution when receiving ACM. 
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Figure 8.4.2.1.4.2.2: Inter-MSC Handover that breaks LCLS when user plane active, completion phase 

14. MSC-1 server sends Handover Command message to BSS-1. 

15. BSS-1 sends Handover Command message to UE-1. BSS-1 will discard incoming user plane data send to 
UE-1 received from CN. If BSS-2 was not instructed to prepare for LCLS related handover in Step 8a, the 
BSS-2 starts bi-casting UP user plane data generated by UE-2 to local path and A interface and also starts to 
check whether there is incoming DL user plane data from the core network. 

NOTE 5: there is no situation where BSS-2 will receive real DL user plane data from the CN at the same 
time as it receives local data from UE-1 as part of the handover. 

16. UE-1 is detected at target BSS. But still no UL data can be sent from target BSS to MGW-1 because Ta-Ts is 
one-way DL only. MGW-1 will continue to transmit DL user plane data to the target BSS-1. BSS-2 continues 
to bi-cast user plane data to both local path and to the A interface. 

17. Target MSC-Server sends MAP-Process- Access-Signal request to the MSC-1 server. 

18a, b. The MSC-1 server uses the Change Flow Direction procedure to request the MGW-1 to set the Handover 
Device to intermediate state and TA-T3 to both- way configuration. When BSS-2 finds out there is DL user 
plane data, BSS-2 will transmit the DL user plane data to UE-2. 

19. Handover Complete message is received from target BSS with LCLS -BSS -status indicating that the call 
cannot be locally switched. 

20. A Handover-Detect/Complete when received is included in the MAP SendEndSignalling Request message 
sent to the MSC-1 server. 
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21. Target MSC-Server sends ANSWER message with the LCLS-status when a Handover-Detect/Complete is 
received. 

22. MSC-1 server informs BSS-1 to clear the old call leg. 

23. MSC-1 server sends LCLS Status Update message with LCLS status "LCLS not connected" to MSC-2 
server. 

NOTE 6: When BICC is used as the call control protocol the APM message is sent. When SIP-I is used the 
INFO request with the encapsulated APM message is sent. 

24. Serving BSS-2 informs MSC-2 server that LCLS is broken via LCLS -Notification message. 

NOTE 7: There is no need to send LCLS -Notification message from BSS-1 after receiving the Clear 
Command message since Clear Complete indicates that LCLS was disconnected. 

25. BSS-1 informs MSC-1 server that the resource for the UE-1 has been released and BSS-2 stops bi-casting. 

26a, b. The MSC-1 server requests MGW-1 to set the Handover Device to its final state by removing the bearer 
termination Ts towards BSC-1 using the Release Termination procedure. 

8.4.2.2 Inter-MSC GSM to GSM Handover that establishes Local Switching 

8.4.2.2.1 General 

When LCLS is not established for a call and an inter-MSC handover occurs that makes the call local, the call should be 
locally switched in the BSS. The Inter-MSC handover procedures specified in 3GPP TS 23.009 [9], 3GPP TS 23.205 
[2] and 3GPP TS 23.231 [3] shall be followed. The following clauses describe the additional requirements for inter- 
MSC handovers that establish LCLS and the differences compared to Inter-MSC handovers that break LCLS are 
identified. 

8.4.2.2.2 MSC-1 / MGW-1 

8.4.2.2.2.1 Handover Required 

When MSC-1 Server receives the Handover Required message from the serving BSS and determines that the call shall 
be handed over to the Target MSC Server, it shall send the GCR of the call, the LCLS -Negotiation Request IE and the 
LCLS -Configuration-Preference IE to the Target MSC Server in a MAP Prepare-Handover_Request message. 

8.4.2.2.2.2 Handover Request Acknowledge 

When MSC-1 Server receives the MAP Prepare_Handover_Response including Handover_Request_Acknowledgement 
message with a LCLS -BSS -Status IE the Anchor MSC-1 Server configures the bearer terminations in MGW-1 and 
sends the GCR IE, the LCLS -Negotiation Request IE and the LCLS -Configuration-Preference IE to the target MSC- 
Server. 

8.4.2.2.2.3 Bearer establishment between MGW-1 and Target MGW 

The handling of the bearer establishment between MGW-1 and Target MGW is as described in sub-clause 6.1 for a 
Basic Mobile Originating Call. The MSC server shall also use the Change Flow Direction procedure to request the 
MGW-1 to set the Handover Device to the initial state. 

8.4.2.2.2.4 MGW Flow Direction Control 

In accordance with the normal handover case the MGW-1 isolates the termination towards the Target MGW (T2) from 
the termination to the Serving BSS (Ts) and configures the Anchor termination (Ti) one-way DL towards the Target 
MGW termination (T2). Termination to the Serving BSS (Ts) is both-way connected to Anchor termination (Ti) since it 
is also receiving UL user data from termination to the Serving BSS (Ts). 
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8.4.2.2.2.5 Handover Command/Handover Detect 

The MSC-1 Server shall use the Change Flow Direction procedure to requests the MGW-1 to set the Handover Device 
to intermediate state. 

8.4.2.2.2.6 Handover Complete 

When the MSC-1 Server receives the Handover Complete message, it releases the A-interface line towards BSS-1. The 
MSC-1 Server also requests MGW-1 to set the Handover Device to its final state by removing the bearer termination 
towards the BSS-1. 

When LCLS has been established during the handover procedure, the target ESS informs the target MSC-Server that 
the call has been locally switched in the Handover Complete message, 

8.4.2.2.3 Target MSC Server / Target MGW 

8.4.2.2.3.1 Prepare Handover Request message and MGW selection 

The Target MSC server selects the Target MGW when it receives Prepare Handover Request message. The Target MSC 
server sends the Handover Request message to the Target BSS as for the normal case but shall include the GCR IE, the 
LCLS -Configuration IE and the LCLS -Connection-Status-Control IE set to "Connect". 

8.4.2.2.3.2 Handover Request Acknowledge 

If the Target BSS supports the LCLS feature it shall include the LCLS -BSS -Status IE in the Handover Request 
Acknowledge message in order to inform the Target MSC Server that the BSS supports the LCLS feature. The Target 
MSC Server sends the same information in the MAP Prepare Handover Response message to the MSC-1 Server. 

8.4.2.2.3.3 Bearer establishment towards Target BSS 

When the Target MSC Server has selected the Target MGW it requests the Target MGW to seize a TDM circuit if 
AoTDM using the Reserve Circuit procedure, or an IP termination if AoIP using the reserve Connection Point 
procedure as for the normal handover procedure. The Target MSC Server sends the Handover Request message to the 
Target BSS containing the CIC for AoTDM or the IP addresses and UDP ports received from the target MGW if AoIP. 

8.4.2.2.3.4 Bearer establishment between MGW-1 and Target MGW 

The handling of the bearer establishment between MGW-1 and Target MGW is as described for basic mobile 
terminating call in sub-clause 6.2. 

8.4.2.2.3.5 LCLS Negotiation in Initial Address message 

If the Target MSC Server receives an Initial Address message that does not include a LCLS -Negotiation Request IE or 
includes a LCLS -Negotiation Request IE set to LCLS is not permitted, the Target MSC Server shall update the 
previously sent LCLS -Configuration by sending a LCLS_CONNECT_CONTROL message to BSS with a LCLS- 
Configuration IE set to LCLS-not allowed and a LCLS_Connection_Status_Control IE set to "do not connect LCLS". 
The inter-MSC handover continues as described in sub-clause 8.4.2.3 Inter-MSC Handover that leaves a not locally 
Switched Call unchanged. 

8.4.2.2.4 Example of Inter-MSC Handover that establishes Local Switching 

8.4.2.2.4.1 Connection Model 

Figure 8.4.2.2.4.1.1 shows the network model for the Basic Inter-MSC GSM to GSM handover when LCLS is 
established as a result of the handover. The dashed line in green represents call control signalling and the dashed line in 
blue represents the user plane connection path via the core network, which should be used if LCLS is not established or 
after LCLS is broken. The non-dotted lines represent the bearer carrying real user plane data. In MGW-1 the bearer 
termination Ts is used for the bearer towards BSS-1, bearer termination Ta is used for the bearer towards the 
succeeding/preceding MGW, that is MGW-2 and bearer termination T3 is used towards the Target MGW. In MGW-2 
the bearer termination T2 is used for the bearer towards BSS-2 and bearer termination Ti is used for the bearer towards 
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MGW-1. In Target-MGW the bearer termination Tt is used towards the Target-BSS and bearer termination T4 is used 
towards MGW-1. 

In this example scenario the Handover Device is located in MGW-1 selected for the call establishment by the MSC-1 
server, which controls the call and mobility management. 

User plane link which transmits real user plane data within BSS and to UE 
User plane link which transmits real user plane data through the CN and to UE 
User plane link path through CN, connected 
Control plane link which transmits signalling 



MSC-l S 



X 



MSC-2 S 



fte^-fe^* e^ 



'1 
I 
I 

I 




Target 



Target 
. MGW^ 



Before Handover 



MSC-l S 



,_''' r 



-• % 

MSC-2 S • ^ 



"tSSr"' S3"* 



Target ^ 

.MSC-: 



BSS-2 



+ 






TargetBSSy' • 



BSS-1 




MGW-1 




Target 



During Handover, T3 is isolated from Ts, Ta is one-way connected to T3 
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After Handover, LCLS is established and both call legs are in Target BSS (=BSS-2) 
Figure 8.4.2.2.4.1.1 : Basic Inter-MSC GSM to GSM Handover (network model) 



8.4.2.2.4.2 



Basic Sequence for Inter-MSC GSM to GSM Handover that establishes Local 
Switching 



Figures 8.4.2.2.4.2.1 and 8.4.2.2.4.2.2 show the message sequence example for the Basic Inter-MSC GSM to GSM 
Handover shown in the corresponding network model Figure 8.4.2.2.4.1.1. The Handover Device is located in MGW-1 
selected for the call establishment by the MSC-l server, which controls the call and the mobility management. The 
description is based on 3GPP TS 23.009 [9], 3GPP TS 23.205 [2] and 3GPP TS 23.231 [3]. 
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Figure 8.4.2.2.4.2.1 : Initial phase of Inter-MSC Handover establishing Local Switching 

1. Handover Required message is received from BSS-1 requesting an inter-MSC handover. The call is currently 
not locally switched. 

2. The MSC-1 server determines that inter-MSC handover is required and sends the Pre-Handover Request 
message to target MSC-Server which includes LCLS Negotiation and GCR. 

3a, b. Target-MSC-Server reserves circuit or Connection Point towards the Target-BSS 

4. Target MSC-Server sends Handover request message to target BSS with GCR and instructs the BSS to 
prepare to connect LCLS. The LCLS -Configuration IE can instruct the BSS to bi-cast user plane data, if 
applicable. 

5. Target BSS performs call leg correlation with GCR to find if another call leg is active with same GCR. The 
BSS reports in Handover Request Acknowledge message that the local call was found but LCLS is not yet 
established. 

5a. The BSS-2 notifies MSC-2 server the LCLS status is changed by sending the LCLS_Notification message 
with the LCLS -BSS -Status IE set to "Call not yet locally switched". 
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5b. If the call has been answered and MSC-2 server permits LCLS to be connected, then the MSC-2 server sends 
to the BSS-2 the LCLS_Connect_Control message with the LCLS-Connection-Status-Control IE set to 
"connect". 

5c. The BSS-2 returns the LCLS_Connect_Control_ACK message with the LCLS -ESS -Status IE set to "Call not 
yet locally switched" . 

6a, b. (These signalling steps are only applicable to AoIP.) When the Target MSC-Server receives the BSSMAP 

Handover Request- Ack message, it sends the BSC-B IP address and UDP Port number to the MGW-B using 
the Configure RTP Connection Point procedure. 

7. The Target MSC-Server sends the Prepare Handover Response message to MSC-1 server. 

8. b. In accordance with normal handover the MSC-1 server requests MGW-1 to isolate the termination towards 

Target MGW (T3) from the termination to the Serving BSS-1 (Ts) and to configure the Anchor termination 
(Ta) one-way DL towards the Target MGW termination (T3). 

9. MSC-Server 1 sends I AM (Initial Address Message) to Target MSC-Server including GCR and configures 
the LCLS-Negotiation IE. 

NOTE 1: Corresponding SIP-I signalling is specified in 3GPP TS 23.231 [3]. 

NOTE 2: The LCLS-Negotiation IE in step 9 can be different from LCLS Negotiation IE in step 2, because 
step 9 is BICC signalling and the IE value can be changed by intermediate MSC-Servers. 

10a, b. Target MSC-Server reserves bearer connection T4 towards MGW-1. 

11. After Target MGW has replied with the bearer address and the binding reference (Step 10b), the Target 
MSC-Server returns the Bearer and Codec Information (APM) message with selected codec, available codec 
Hst and the LCLS-Negotiation IE. 

12. Target MSC-Server sends ACM (Address Complete Message). Target MSC-Server awaits the capturing of 
the UE-1 on the radio path when the ACM is sent and MSC-1 server initiates the handover execution when 
receiving ACM. 
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Figure 8.4.2.2.4.2.2: Completion phase of Inter-MSC Handover establishing Local Switching 

13-18. When the local switching has been established during the handover procedure, the target BSS shall inform 
the target MSC-Server that the call has been locally switched in Handover Complete message, and the target 
BSS shall also send a new message LCLS -Notification with LCLS-BSS-Status IE to inform the MSC-2 
server that the local switching has been established. In steps 16a and 16b the MSC-1 server configures 
MGW-1 for the completion of the handover. 

19. A Handover-Detect/Complete when received is included in the MAP-Send-End-Signalling request and sent 
back to the MSC-1 server. 

20. Target MSC-Server sends ANSWER message with the LCLS-status when A-HO-DETECT/COMPLETE is 
received. 

21. MSC-Server 1 clears the call in BSS-1. 

22. MSC-1 server (Anchor MSC-Server) sends LCLS -Status-Update message to the far end MSC-2 server. 

NOTE 3: When BICC is used as the call control protocol the APM message is sent. When SIP-I is used the 
INFO request with the encapsulated APM message is sent. 

23. BSS-1 informs MSC-1 server that the resource for the UE-1 has been released 
24a, b. MSC-1 server releases the bearer termination towards BSS-1. 

25. Local switching is established in the BSS. 
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8.4.2.3 Inter-MSC Handover that leaves a not Locally Switched Call unchanged 

In this scenario it is assumed that LCLS was not estabhshed before the Inter-MSC handover. When one call leg is 
handed over to another MSC-Server, the call still remains not local. LCLS cannot be established for the call and the 
LCLS status of the call is not changed. 

For the Anchor MSC-1 server and Target MSC server this Inter-MSC handover is similar to the Inter-MSC handover 
that establishes LCLS as described in sub-clause 8.4.2.2.4.2 until Step 5, but in this case in Step 5 the Target BSS sends 
the Handover Request ACK message, where the LCLS -BSS -Status IE indicates that the call is not possible to be locally 
switched since the GCR correlation will indicate that the call is not local. Steps 5a, 5b, 5c will not be triggered. The 
handover procedure is completed as for a non-local call, LCLS is not established and the LCLS Status in the core 
network is not changed. 

8.4.3 Subsequent Inter-MSC GSM to GSM Handover back to the Anchor 
MSC 

The basic Inter-MSC GSM to GSM handover procedure as specified in this specification shall be applied. 

8.4.4 Subsequent GSM to GSM Handover to a third MSC 

The basic GSM to GSM handover procedure as specified in this specification shall be applied. 

8.4.5 BSS Internal Handover 

8.4.5.1 General 

The following procedures describe the specific handling compared to the basic principles described in 3GPP TS 23.205 
[2] sub-clause 8.4.5 to achieve BSS Internal Handover with LCLS for an A-interface User Plane over IP (AoIP). 

If the call is not locally switched but both call legs have been correlated and an internal handover occurs that makes the 
call local, the call should be locally switched in the BSS. 

If a call is currently locally switched and an internal handover occurs that makes the call not local, the local switching 
should be broken in the BSS and the user plane data shall be connected through the core network. 

NOTEl : For A-interface User Plane over TDM (AoTDM), a BSS internal handover that results in LCLS break will 
trigger a BSS Initiated LCLS Break according to procedures in sub-clause 7.2.2. 

If an internal handover procedure occurs that does not modify the LCLS status of a call, the local switching should not 
be modified within the BSS. 

8.4.5.2 Internal Handover Required 

If the MSC Server accepts the Internal Handover Required message it shall send an Internal Handover Command 
message to the BSS. If the call is currently locally switched in the BSS, the MSC Server shall also signal LCLS-Status- 
Change Request message containing LCLS -Status-Change IE set to "LCLS Disconnection Preparation for Handover" 
through the core network to enable UL bi-casting during handover. 

The MSC Server shall not wait for the LCLS -Status-Change Request Acknowledge message before proceeding with the 
Internal Handover. 

8.4.5.3 Internal Handover Command 

If local switching is permitted by the core network and the MSC Server has not previously requested that the BSS 
should connect the local call, (e.g. no previous LCLS-Connection-Status-Control = "Connect"), the MSC Server shall 
include the LCLS-Connection-Status-Control IE indicating "Connect" in the Internal Handover Command message. 

Otherwise, the MSC Server shall send the Internal Handover Command message according to the procedures in 3GPP 
TS 48.008 [7]. 
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8.4.5.4 



Handover Complete 



The BSS sends Handover Complete message including the LCLS-BSS -Status that indicates whether the call is locally 
switched (e.g. "Call is Locally Switched with requested LCLS configuration " or "the call is no longer locally 
switched"). 

The MSC server shall send to an adjacent call node the LCLS-Status-Update message with the LCLS-Status IE 
indicating the new LCLS Status (e.g. "LCLS connected" or "LCLS Not Connected"). 

8.4.5.5 Example BSS Internal Handover that Establishes Local Switching 

8.4.5.5.1 Connection Model 

Figure 8.4.5.5.1.1 shows the network model for the Intra-MSC BSS Internal Handover, where the call leg pertinent to 
the UE-1 is handed over from the serving BSS-1 to BSS-2. BSS-1 is the same as BSS-2 for BSS Internal Handover. The 
bearer termination T2 is used for the bearer towards BSS-2, which is not affected by this handover. Bearer termination 
Ts is used for the bearer towards BSS-1 and the bearer terminations Ti and Ta are used for the bearer towards the 
succeeding/preceding MGW. Bearer termination Tt is for the bearer termination towards the BSS after internal 
handover. The colours and line types used in the figure are defined differently from 3GPP TS 23.205 [2] to indicate 
LCLS specific issues. 

^^^^ User plane link which transmits real user plane data within the BSS and to UEs 

^^^^ User plane link which transmits real user plane data through the ON and to UEs 

• • • User plane path through the ON, connected 

w w • Control plane link which transmits signalling 
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Before Handover 



Connection Model 1 : Before BSS Internal Handover - Call is not locally switched 
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Connection Model 3: After BSS Internal Handover - Call is Locally Switched 
Figure 8.4.5.5.1.1: BSS Internal Handover Connection Model that Establishes Local Switching 



8.4.5.5.2 



Basic Sequence for BSS Internal Handover that Establishes Local Switching 



Figure 8.4.5.5.2.1 shows the message sequence example for the BSS Internal Handover that Establishes Local 
Switching. 

In the example, the MSC server receives the Internal Handover Required message and requests the MGW to reserve an 
RTP bearer termination (Tt) using the Reserve and Configure RTP Connection Point procedure with specific flow 
directions. 
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ure 8.4.5.5.2.1 : BSS Internal Handover for AolP that Establishes Local Switching 

1-2. As for normal Internal Handover, see TS 23.205 [2] sub-clause 8.4.5. 

3. The MSC-1 Server determines that local switching is permitted by the core network and sends the Internal 

Handover Command message, including the LCLS -Connection-Control-Status message indicating "Connect" 
if not previously indicated to BSS- L 

3a. The BSS-2 notifies MSC-2 server the LCLS status is changed by sending the LCLS_Notification message 
with the LCLS-BSS-Status IE set to "Call not yet locally switched". 

3b. If the call has been answered and MSC-2 server permits LCLS to be connected, then the MSC-2 server sends 
to the BSS-2 the LCLS_Connect_Control message with the LCLS-Connection-Status-Control IE set to 
"connect". 

3c. The BSS-2 returns the LCLS_Connect_Control_ACK message with the LCLS-BSS-Status IE set to "Call not 
yet locally switched" . 

4-5. As for normal Internal Handover, see TS 23.205 [2] sub-clause 8.4.5. 

6. The Handover Complete message includes the LCLS-BSS-Status IE indicating that call is locally switched. 
NOTE: alternatively the BSS-1 could indicate LCLS-BSS-Status IE in LCLS -Notification message. 

7. The LCLS Status is propagated through the Core Network. 
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The BSS-2 sends the LCLS_Notification message to MSC-2 server with the LCLS-BSS -Status IE set to "call 
is locally switched with requested LCLS configuration" . 

The termination (Ts) is removed from the Access MGW-1. 



8.4.5.6 



Example BSS Internal Handover that Breaks Local Switching 



8.4.5.6.1 



Connection Model 



Figure 8.4.5.6.1.1 shows the network model for the Intra-MSC BSS Internal Handover, where the call leg pertinent to 
the UE-1 is handed over from the serving BSS-1 to BSS-2. BSS-1 is the same as BSS-2 for BSS Internal Handover. The 
bearer termination T2 is used for the bearer towards BSS-2, which is not affected by this handover. Bearer termination 
Ts is used for the bearer towards BSS-1 and the bearer terminations Ti and Ta are used for the bearer towards the 
succeeding/preceding MGW. Bearer termination Tt is for the bearer termination towards the BSS after internal 
handover. The colours and line types used in the figure are defined differently from 3GPP TS 23.205 [2] to indicate 
LCLS specific issues. 

^^^^ User plane link which transmits real user plane data within the BSS and to UEs 

^^^^ User plane link which transmits real user plane data through the ON and to UEs 

• • • User plane path through the ON, connected 

• MM Control plane link which transmits signalling 
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Connection Model 1 : Before BSS Internal Handover - Call is locally switched 
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Connection Model 3: After BSS Internal Handover - Call is not Locally Switched 
Figure 8.4.5.6.1.1: BSS Internal Handover Connection Model that Breaks Local Switching 

8.4.5.6.2 Basic Sequence for BSS Internal Handover that Breaks Local Switching 

Figure 8.4.5.6.2.1 shows the message sequence example for the BSS Internal Handover that Breaks Local Switching. 

In the example, the MSC server receives the Internal Handover Required message and requests the MGW to reserve an 
RTP bearer termination (Tt) using the Reserve and Configure RTP Connection Point procedure with specific flow 
directions. 
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Figure 8.4.5.6.2.1 : BSS Internal Handover for AolP that Breaks Local Switching 

1-2. As for normal Internal Handover, see TS 23.205 [2] sub-clause 8.4.5. 

3. MSC-1 Server indicates preparation for disconnection due to handover through the Core Network. 
MSC-2 Server indicates to BSS-2 to start UL bicasting. 



3a. 
3b. 

3c. 
4. 

4a 

5. 



The BSS-2 sends the LCLS_Connect_Control_Ack message with the LCLS -BSS -Status IE set to "the call is 
locally switched with requested LCLS configuration ". 

MSC-2 Server sends LCLS-Status-Change-Request- Acknowledgement. 

The MSC-1 Server determines that local switching is permitted by the core network and sends the Internal 
Handover Command message, optionally including the LCLS -Connection-Control- Status message indicating 
"Connect". 

BSS-1 may indicate Handover Detected. 

BSS-1 sends the Handover Complete message to MSC-1 Server to indicate LCLS -BSS -Status is set to "Call 
is no longer locally switched" . 



6. MSC-1 Server propagates the change of the LCLS Status through the Core Network. 

NOTE: If the Internal Handover did not in the end result in LCLS break then the MSC Server will send 
LCLS-Status-Update message indicating that the call is locally switched. 

7. BSS-2 indicates that the call is no longer locally switched in the LCLS_NOTIFICATION message. 
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8. The old termination (Ts) is removed and the call is normally switched through the Core Network. 

8.4.5.7 Example BSS Internal Handover that Does Not Modify LCLS Status of a 

Locally Switched Call 

8.4.5.7.1 Connection Model 

Figure 8.4.5.7.1.1 shows the network model for the Intra-MSC BSS Internal Handover, where the call leg pertinent to 
the UE-1 is handed over from the serving BSS-1 to BSS-2. BSS-1 is the same as BSS-2 for BSS Internal Handover. The 
bearer termination T2 is used for the bearer towards BSS-2, which is not affected by this handover. Bearer termination 
Ts is used for the bearer towards BSS-1 and the bearer terminations Ti and Ta are used for the bearer towards the 
succeeding/preceding MGW. Bearer termination Tt is for the bearer termination towards the BSS after internal 
handover. The colours and line types used in the figure are defined differently from 3GPP TS 23.205 [2] to indicate 
LCLS specific issues. 

^^^^ User plane link which transmits real user plane data within the BSS and to UEs 

^^^^ User plane link which transmits real user plane data through the ON and to UEs 

• • • User plane path through the ON, connected 

M M M Control plane link which transmits signalling 
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>J(^\1 M^' 
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Connection Model 1 : Before BSS Internal Handover - Call is locally switched 
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UE-2 



UE-1 




During Handover * 
Ts = Serving 
Ta = Anchor 
Tt = Target 



Connection Model 2: During BSS Internal Handover 



UE-2 



UE-1 




After Handover 



Connection Model 3: After BSS Internal Handover - Call is Locally Switched 

Figure 8.4.5.7.1.1 : BSS Internal Handover Connection Model that Does Not Modify LCLS Status of a 

Locally Switched Call 

8.4.5.7.2 Basic Sequence for BSS Internal Handover that Does Not Modify LCLS Status of 

a Locally Switched Call 

Figure 8.4.5.7.2.1 shows the message sequence example for the BSS Internal Handover that Does Not Modify LCLS 
Status of a Locally Switched Call. 

In the example, the MSC server receives the Internal Handover Required message and requests the MGW to reserve an 
RTP bearer termination (Tt) using the Reserve and Configure RTP Connection Point procedure with specific flow 
directions. 
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Figure 8.4.5.7.2.1 : BSS Internal Handover for AolP that Does Not Modify LCLS Status of a Locally 

Switched Call 

1-2. As for normal Internal Handover, see TS 23.205 [2] sub-clause 8.4.5. 

3. MSC-1 Server indicates preparation for disconnection due to handover through the Core Network. 
MSC-2 Server indicates to BSS-2 to start UL bicasting. 



3a. 
3b. 

3c. 
4. 

4a 

5. 



The BSS-2 sends the LCLS_Connect_Control_Ack message with the LCLS -BSS -Status IE set to "the call is 
locally switched with requested LCLS configuration" . 

MSC-2 Server sends LCLS-Status-Change-Request- Acknowledgement. 

The MSC-1 Server determines that local switching is permitted by the core network and sends the Internal 
Handover Command message, optionally including the LCLS -Connection-Control- Status message indicating 
"Connect". 

BSS-1 may indicate Handover Detected. 

BSS-1 sends the Handover Complete message to MSC-1 Server to indicate LCLS -BSS -Status is set to "the 
call is locally switched with requested LCLS configuration" . 



6. The old termination (Ts) is removed and the call is normally switched through the Core Network. 
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8.4.5.8 Example BSS Internal Handover that Does Not Modify LCLS Status of a non- 

Locally Switched Call 

8.4.5.8.1 Connection Model 

Figure 8.4.5.8.1.1 shows the network model for the Intra-MSC BSS Internal Handover, where the call leg pertinent to 
the UE-1 is handed over from the serving BSS-1 to BSS-2. BSS-1 is the same as BSS-2 for BSS Internal Handover. The 
bearer termination T2 is used for the bearer towards BSS-2, which is not affected by this handover. Bearer termination 
Ts is used for the bearer towards BSS-1 and the bearer terminations Ti and Ta are used for the bearer towards the 
succeeding/preceding MGW. Bearer termination Tx is for the bearer termination towards the BSS after internal 
handover. The colours and line types used in the figure are defined differently from 3GPP TS 23.205 [2] to indicate 
LCLS specific issues. 

^^^^ User plane link which transmits real user plane data within the BSS and to UEs 

^^^^ User plane link which transmits real user plane data through the CN and to UEs 

• • • User plane path through the CN, connected 

w w M Control plane link which transmits signalling 
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Connection Model 1 : Before BSS Internal Handover - Call is not locally switched 
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Connection Model 2: During BSS Internal Handover 




UE-2 



UE-1 



^(^>4-^ 



Non-LCLS User Plane 




After Handover 



Connection Model 3: After BSS Internal Handover - Call is not Locally Switched 

Figure 8.4.5.8.1.1 : BSS Internal Handover Connection Model that Does Not Modify LCLS Status of a 

non-Locally Switched Call 

8.4.5.8.2 Basic Sequence for BSS Internal Handover that Does Not Modify LCLS Status of 

a non-Locally Switched Call 

Figure 8.4.5.8.2.1 shows the message sequence example for the BSS Internal Handover that Does Not Modify LCLS 
Status of a Locally Switched Call. 

In the example, the MSC server receives the Internal Handover Required message and requests the MGW to reserve an 
RTP bearer termination (Tt) using the Reserve and Configure RTP Connection Point procedure with specific flow 
directions. 



ETSI 



3GPP TS 23.284 version 10.3.0 Release 10 



129 



ETSI TS 123 284 VI 0.3.0 (2012-01) 



UE-1 



BSS-1 



3. Int|ernal 
(LCLS-i 



MSC-1 



MGW-1 



1. Internal 



2. Conte}(tC1: ADD 

( 

(T 



Termination Tt 

, Tt) - isolate; 

^, Tt) - bothway 



Hand 
C(bnnection 



)ver Command 

Qontrol-Status = 

Connect") 



Handover 
Detected In 
Target Cell 



Call 



[3a. Hancover Detected] 



4. Han 

(LCL^- 
is not l0( 



5. Cont 



Handover Required 



doverComplete 

BSS-Status = 

:ally switched" ^ 



ixtC1:SUBTs 



MSC-2 



Normally Switched User Plane 



Normally Switched User Plane 



BSS-2 



MGW-2 



UE-2 



Figure 8.4.5.8.2.1 : BSS Internal Handover for AolP that Does Not Modify LCLS Status of a non-Locally 

Switched Call 

1-2. As for normal Internal Handover, see TS 23.205 [2] sub-clause 8.4.5. 

3. The MSC-1 Server determines that local switching is permitted by the core network and sends the Internal 
Handover Command, optionally including the LCLS-Connection-Control-Status message indicating 
"Connect". 

3a BSS-1 may indicate Handover Detected. 

4. BSS-1 sends the Handover Complete message to MSC-1 Server to indicate LCLS -BSS -Status is set to "Call 
is not locally switched" . 

5. The old termination (Ts) is removed and the call is normally switched through the Core Network. 

8.5 Handling of GSM Services after UMTS to GSM Handover 

No impact. There are no LCLS related requirements for the handling of GSM Services after UMTS to GSM Handover. 

The handling of GSM services after UMTS to GSM Handover shall be applied in accordance with 3GPP TS 23.205 [2] 
sub-clause 8.5 for Bearer-Independent CS Core Networks. 
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9 Compatibility Issues 

None; this feature is backward compatible with existing features and earUer releases. 

1 General (G)MSC server-MGW Procedures 

LCLS does not modify the general (G)MSC server-MGW procedures as shown in 3GPP TS 23.205 [2]. 



1 1 Identities 

11.1 General 

The Identities defined in 3GPP TS 23.205 [2] for BIGG based GS Gore network and in 3GPP TS 23.231 [3] for SIP-I 
with the following additions. 

1 1 .2 Global Call Reference 

The Global Gall Reference (GGR) IE is derived from the ITU-T Global Call Reference parameter (defined by ITU-T 
Q.1902.3 [5]). 

The Global Gall Reference (GGR) information element is a combination of a Network ID field, a Node ID field and a 
Gall Reference ID field. The Gall Reference ID field for LGLS is defined to contain a unique call ID. 

If the serving radio access is GERAN the Gall Reference ID subfield created by originating MSG server contains a 
unique call ID and the originating BSS ID which is a unique identifier of a Base Station Subsystem (BSS) Node within 
an operator's network. 

The complete parameter layout is specified in 3GPP TS 29.205 [6]. 

The GGR is exchanged on the Nc and A interfaces to globally identify the call. 



1 2 Operational Aspects 
12.1 Charging 

No impact. 



1 3 Interactions with Other Services 

13.1 Enhanced Multi-Level Precedence and Pre-emption service 
(eMLPP) 

No impact. eMLPP is always done during call set-up and handled by the MSG Server and therefore such calls can be 
locally switched. 
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13.2 Call Deflection Service 

13.2.1 General 

The procedures specified for the Call Deflection (CD) supplementary services in 3GPP TS 23.205 [2] sub-clause 13.2 
for BICC based CS Core Network and in 3GPP TS 23.231 [3] sub-clause 13.2 for SIP-I based CS Core Network shall 
be followed. The following sub-clauses describe the additional requirements related to the LCLS functionality. 

The incoming call shall be offered to the served subscriber as a basic mobile terminated call as described in the first part 
of sub-clause 6.3.2. If the Call Deflection (CD) supplementary service is active and a Call Deflection request from the 
served subscriber is accepted the call shall be forwarded towards the forwarded-to subscriber. 

The basic call establishment procedures defined in Clause 6 shall be followed for the call towards the forwarded-to 
(deflected-to) subscriber. The MSC server shall release the call leg towards the served subscriber as described in the 
sub-clause 7.1 for call clearing. 

1 3.2.2 Notification to the Calling Subscriber 

If the served mobile subscriber has requested that the calling subscriber shall receive a notification about the call 
forwarding, a notification is sent to the calling party. 

If the notification is implemented using intermediate tones or announcements the MSC server requests the MGW to 
play an announcement/tone to the calling party, as described in sub-clause 14.6, before establishing the call to the 
forwarded-to subscriber. 

13.2.3 Initial Addressing 

After the possible generation of in-band information has been completed the initial addressing towards the forwarded-to 
subscriber is performed as described in Clause 6 for the basic mobile terminating call. If the forwarding MSC server 
supports the LCLS feature and has received the GCR IE, the LCLS -Negotiation Request IE and LCLS -Configuration- 
Preference IE from a preceding node in the I AM it shall then forward the GCR IE and the resulting LCLS- 
Configuration-Preference IE and the LCLS -Negotiation Request IE to the succeeding node. 

1 3.2.4 Backward LCLS Negotiation 

The procedure specified in sub-clause 6.2.1.2.2 for the intermediate node and in sub-clause 6.1.1.4 for the oMSC server 
shall be applied. 

13.2.5 LCLS Through-Connection 

The procedure specified in sub-clause 6.1.1.5 shall be applied. 

13.2.6 Example 
13.2.6.1 Connection Model 

Figure 13.2.6.1.1 shows the network model for Call Deflection (CD). 

The oMSC server seizes one context with two bearer terminations in the oMGW. The bearer termination Tl is used for 
the bearer towards the oBSS (calling subscriber) and the bearer termination T2 is used for the bearer towards the GMSC 
selected iMGW. The GMSC server seizes one context with two bearer terminations in the iMGW. The bearer 
termination T4 is used for the bearer towards the sMSC server selected sMGW and the bearer termination T3 is used for 
the bearer towards the preceding oMGW. The sMSC server seizes one context with two bearer terminations in the 
sMGW. The bearer termination T5 is used for the bearer towards the GMSC selected iMGW and bearer termination Ts 
is used for the bearer towards the sBSS (served subscriber). 

After a call deflection request is accepted the sMSC server replaces the bearer termination for the served mobile 
subscriber Ts with the bearer termination for the forwarded-to subscriber T6 in an existing context in the sMGW. 
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The tMSC server seizes one context with two bearer terminations in the tMGW. The bearer termination T7 is used for 
the bearer towards the sMSC selected sMGW and bearer termination T8 is used for the bearer towards the tBSS 
(forwarded-to subscriber). 
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Connection Model 3: CD, After Answer, Call locally switched 
Figure 13.2.6.1.1: Connection Model for Call Deflection 
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13.2.6.2 Basic Sequence 

Figures 13.2.6.2.1 and 13.2.6.2.2 show the message sequence example for the call deflection with a possible notification 
to the calling party using an announcement. In the example the sMSC server optionally requests the sMGW to play an 
announcement and to notify the announcement completion. The sMSC server requests the establishment of the call and 
the bearer towards the forward-to subscriber after the possible announcement has completed. In this example the calling 
subscriber (oUE) and the forwarded-to subscriber (tUE) belong to the same BSS (marked as oBSS and tBSS) and the 
CN permits LCLS. This example is based on examples from clause 6. 
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For call establishment towards served subscriber sUE see basic call establishment, subclause 6.3.2, Steps 1 - 24 
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Figure 13.2.6.2.1: CD, Call Establishment Flow 

The incoming call is offered to the served subscriber as a basic mobile terminated call as described in the first 
part of sub-clause 6.3.2. The Call Deflection (CD) supplementary service is active and a Call Deflection is 
requested from the served subscriber sUE. 

The Call Deflection is accepted. 

The sMSC server initiates call clearing towards the sUE by sending a DISCONNECT message. 

Upon receiving the DISCONNECT message the sUE sends a RELEASE message to the core network. 

The sMSC server sends the RELEASE COMPLETE message to the sUE. 

The sMSC server request the sBSS to release the associated dedicated resource(s) by sending CLEAR 
COMMAND message. 

The sBSS informs the sMSC server that the associated dedicated resource(s) has been successfully cleared 
with the CLEAR COMPLETE message. 

The sMSC server orders the sMGW to remove the bearer termination (Ts) towards the served mobile 
subscriber (in case when the radio resources had already been allocated in the sMGW). 
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9. The sMSC server sends the CPG message with the Generic Notification Indicator parameter set to "Call is 
diverting". 

10. The sMSC server provides the sMGW with the announcement/tone identification and requests the sMGW to 
notify the announcement/tone completion using the Play Announcement or Send Tone procedure. 

11. The GMSC server forwards the CPG message with the Generic Notification Indicator parameter set to "Call 
is diverting" to the preceding node. 

12. The oMSC server notifies the calling user (oUE) about call forwarding. 

13. The sMGW notifies the sMSC server when the announcement/tone is completed using the Announcement 
Completed or Tone Completed procedure. 
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23. For succeeding signalling sequence see basic call establishment, figures 6.3.2.2 and 6.3.2.3, steps 18-32 
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Figure 13.2.6.2.2: CD, Call Establishment Flow (continuation of figure 13.2.6.2.1) 

14. If the sMSC server supports LCLS it may modify the LCLS-Negotiation IE before sending the I AM message 
containing the GCR with the encapsulated oBSS ID and the LCLS-Negotiation IE. 

15. The tMSC server pages the forwarded-to subscriber (tUE). 

16. The tMSC server performs call Setup. 
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17. The tUE confirms the call. 

18. The tMSC server requests the tMGW to prepare for the network side bearer establishment (T7). 

19. After the tMGW has repHed with the bearer address and the binding reference the tMSC server returns the 
APM message with the selected codec and if LCLS is supported, the LCLS -Negotiation IE. 

20. The sMSC server transfers the APM message with the LCLS -Negotiation IE. If codec modification is 
required then the sMSC server includes the codec related information within the same APM message. 

21. The GMSC server transfers the APM message. 

22. Based on the returned LCLS -Negotiation IE the oMSC server determines whether LCLS is allowed in the 
core network and if LCLS -Configuration update is needed. 

If codec modification is required then the oMSC server performs codec negotiation according to 3GPP TS 
23.153 [4]. 

23. When performing further call establishment the procedure between the calling subscriber (oUE) and the 
forwarded-to subscriber (tUE) is the same as specified in steps 18 - 32 of sub-clause 6.3.2.1. 

24. Since the received ANM message indicated "LCLS is feasible but not yet connected" the oMSC server 
checks if LCLS -Configuration updated is needed and if so the oMSC server calculates the new LCLS- 
Configuration value based on the latest received LCLS -Negotiation IE. 

25. The oMSC server requests the oBSS to connect LCLS and if configuration updated is needed, it includes the 
LCLS-Configuration IE in the LCLS_CONNECT_CONTROL message. 

26a. Since the ESS has received the through connect request for both call legs the oBSS returns the 

LCLS_CONNECT_CONTROL_ACK message with the LCLS -BSS -Status IE set to "the call is locally 
switched with requested LCLS configuration" . 

26b. Since the BSS has received the through connect request for both call legs the tBSS signals the LCLS status 
change by sending the LCLS_NOTIFICATION message with the LCLS -BSS -Status IE set to "the call is 
locally switched with requested LCLS configuration" . 

27. The oMSC server signals the change of the LCLS status through the Core Network by sending the APM 
message with the LCLS-Status IE set to "LCLS connected". 

28. The iMSC server transfers the change of the LCLS status to the sMSC server. 

29. The sMSC server transfers the change of the LCLS status to the tMSC server. 

13.3 Line identification Services 

13.3.1 Calling Line Identification Presentation (CLIP) 

No impact. The line identification related services are signalling based and there are no LCLS related requirements for 
the Calling Line Identification Presentation (CLIP) service. 

13.3.2 Calling Line Identification Restriction (CLIR) 

No impact. The line identification related services are signalling based and there are no LCLS related requirements for 
the Calling Line Identification Restriction (CLIR) service. 

13.3.3 Connected Line Identification Presentation (COLP) 

No impact. The line identification related services are signalling based and there are no LCLS related requirements for 
the Connected Line Identification Presentation (COLP) service. 
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13.3.4 Connected Line Identification Restriction (COLR) 

No impact. The line identification related services are signalling based and there are no LCLS related requirements for 
the Connected Line Identification Restriction (COLR) service. 

13.4 Call Forwarding Services 

13.4.1 Principles 

The procedures specified for the Call Forwarding services in 3GPP TS 23.205 [2] sub-clause 13.4 for BICC based CS 
Core Network and in 3GPP TS 23.231 [3] sub-clause 13.4 for SIP-I based CS Core Network shall be followed. The 
following sub-clauses describe the additional requirements related to the LCLS functionality. 

13.4.2 Call Forwarding Unconditional (CFU) 

1 3.4.2.1 Notification to the Calling Subscriber 

If the GMSC server determines that a call should be forwarded without being offered to the served mobile subscriber 
and the served mobile subscriber has requested that the calling subscriber shall receive a notification about the call 
forwarding, the GMSC server shall send a notification to the preceding node. If the GMSC server supports the LCLS 
feature and receives the GCR IE, the LCLS -Negotiation Request IE and LCLS -Configuration-Preference IE from the 
preceding node it may modify the LCLS -Configuration-Preference IE based on its own LCLS configuration 
requirements, as described in sub-clause 4.2, and it shall return the resulting LCLS -Configuration-Preference IE and the 
LCLS -Negotiation Response IE to the preceding node. 

If the notification is implemented using intermediate tones or announcements the GMSC server requests the MGW to 
play an announcement/tone to the calling party, as described in sub-clause 14.6, before establishing the call to the 
forwarded-to subscriber. 

13.4.2.2 Initial Addressing 

If the incoming call is to be forwarded without being offered to the served mobile subscriber the call towards the 
forwarded-to subscriber is established as for a basic call. After the possible generation of in-band information has been 
completed the initial addressing towards the forwarded-to subscriber is performed as described in the clause 6 for the 
basic mobile terminating call. If the GMSC server supports the LCLS feature and receives the GCR IE, the LCLS- 
Negotiation Request IE and LCLS -Configuration-Preference IE from a preceding node in the I AM it shall forward the 
GCR IE and the resulting LCLS -Configuration-Preference IE and the LCLS -Negotiation Request IE to the succeeding 
node. 

13.4.2.3 Backward LCLS Negotiation 

The procedure specified in sub-clause 6.2.L2.2 for the intermediate node and in sub-clause 6.L1.4 for the oMSC server 
shall be applied. 

1 3.4.2.4 LCLS Through-Connection 

The procedure specified in sub-clause 6.LL5 shall be applied. 

13.4.2.5 Example 
13.4.2.5.1 Connection Model 

Figure 13.4.2.5. LI shows the network model for call forwarding unconditional. The oMSC server seizes one context 
with two bearer terminations in the oMGW. The bearer termination Tl is used for the bearer towards the oBSS (calling 
subscriber) and the bearer termination T2 is used for the bearer towards the GMSC selected iMGW. The GMSC server 
seizes one context with two bearer terminations in the iMGW. The bearer termination T4 is used for the bearer towards 
the tMSC server selected tMGW and the bearer termination T3 is used for the bearer towards the preceding oMGW. 
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The tMSC server seizes one context with two bearer terminations in the tMGW. The bearer termination T5 is used for 
the bearer towards the GMSC selected iMGW and bearer termination T6 is used for the bearer towards the tBSS 
(forwarded-to subscriber). 



Control plane link which transmits signalling 

User plane link path through CN, connected or disconnected 

User plane link which transmits real user plane data within BSS and UEs 

User plane link which transmits real user plane data in backward direction 
from the CN towards oUE (e.g. announcement/tone, network provided 
ring-back tone) 



tUE 



oUE. 



13.4.2.5.2 



Control Signalling 

^.... ......... 



oUE« 



'W 




oBSS 







Connection Model 1: Before CFU, Announcement towards Calling Party 




Connection Model 2: After CFU and answer, Call is locally switched 
Figure 13.4.2.5.1.1: Connection Model for Call Forwarding Unconditional 

Basic Sequence 



Figures 13.4.2.5.2.1 and 13.4.2.5.2.2 show the message sequence example for the call forwarding unconditional with a 
possible notification to the calling party using an announcement. In the example the GMSC server optionally requests 
the MGW to play an announcement and to notify the announcement completion, after the bearer to the incoming side 
has been established. When the possible announcement has completed the GMSC server requests the establishment of 
the call and the bearer towards the forward-to subscriber. 

In this example the calling subscriber (oUE) and the forwarded-to subscriber (tUE) belong to the same BSS (marked as 
oBSS and tBSS) and the CN permits LCLS. The example is based on examples from clause 6. 
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Figure 13.4.2.5.2.1: CFU, Call Establishment Flow 

1. Service Request handling. 

2. Originating Call SETUP. 

3. If the oMSC server supports LCLS it retrieves the oBSS ID and generates the Global Call Reference for the 
call. 

4. The oMSC server sends the lAM message including supported codecs list, GCR with encapsulated oBSS ID, 
and configures the LCLS-Negotiation IE. 

5. The GMSC server determines that call should be forwarded because of the Call Forwarding Unconditional 
supplementary service and that notification should be send towards the calling party (oUE). 

6. Since bearer must be established for the announcement/tone to be sent to the calling party the GMSC server 
selects the MGW and requests the seizure of the incoming network side bearer termination (T3). 

7. The GMSC server transfers the APM message with the selected codec and since LCLS is supported the 
currently negotiated LCLS-Negotiation IE. 

8a. When the bearer information is received the oMSC server requests the seizure of the network side bearer 
termination (T2). 
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8b. After the network side bearer information is seized the oMSC server requests the seizure of the access side 
bearer termination (Tl). 

During the seizure of the network side or the access side bearer termination the oMSC server will also 
request the oMGW to through-connect the bearer terminations so that the bearer will be backward through- 
connected. 

9. The oMSC server determines whether LCLS is allowed in the core network based on the returned LCLS- 
Negotiation IE and if so the oMSC server includes the LCLS -Configuration IE in the ASSIGNMENT 
REQUEST message along with the GCR IE. 

10. The oBSS returns the ASSIGNMENT COMPLETE message with the LCLS -BSS -Status IE indicating "call 
not possible to be locally switched". 

IL When the access assignment is completed the oMSC server sends the Continuity (COT) message to the 
GMSC server. 

12. The GMSC server sends the ACM message with the Generic Notification Indicator parameter set to "Call is 
diverting". 

13. The GMSC server provides the iMGW with the announcement/tone identification and requests the iMGW to 
notify the announcement/tone completion using the Play Announcement or Send Tone procedure. 

14. The oMSC server notifies the calling user (oUE) about call forwarding. 
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24. For succeeding signalling sequence see basic call establishment, figures 6.3.2.2 and 6.3.2.3, steps 18-32 
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Figure 13.4.2.5.2.2: CFU, Call Establishment Flow (continuation of figure 13.4.2.5.2.1) 

15. The iMGW notifies the GMSC server when the announcement/tone is completed using the Announcement 
Completed or Tone Completed procedure. 

16. If the GMSC server supports LCLS it may modify the LCLS-Negotiation IE before sending the lAM 
message containing the GCR with the encapsulated oBSS ID and the LCLS-Negotiation IE. 

17. The tMSC server pages the forwarded-to subscriber (tUE). 

18. The tMSC server performs call Setup. 

19. The tUE confirms the call. 

20. The tMSC server requests the tMGW to prepare for the network side bearer establishment (T5). 

21. After the tMGW has replied with the bearer address and the binding reference the tMSC server returns the 
APM message with the selected codec and if LCLS is supported, the LCLS-Negotiation IE. 

22. The GMSC server transfers the APM message with the LCLS-Negotiation IE. If codec modification is 
required then the GMSC server initiates codec negotiation according to 3GPP TS 23.153 [4], and includes the 
codec related information within the same APM message. 
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23. Based on the returned LCLS -Negotiation IE the oMSC server determines whether LCLS is allowed in the 
core network and if LCLS -Configuration update is needed. 

If codec modification is required then the oMSC server performs codec negotiation according to 3GPP TS 
23.153 [4]. 

24. When performing further call establishment the procedure between the calling subscriber (oUE) and the 
forwarded-to subscriber (tUE) is the same as specified in steps 18 - 32 of sub-clause 6.3.2.1. 

25. Since the received ANM message indicated "LCLS is feasible but not yet connected" the oMSC server 
checks if LCLS -Configuration updated is needed and if so the oMSC server calculates the new LCLS- 
Configuration value based on the latest received LCLS -Negotiation IE. 

26. The oMSC server requests the oBSS to connect LCLS and if configuration updated is needed, it includes the 
LCLS-Configuration IE in the LCLS_CONNECT_CONTROL message. 

NOTE: If codecs need to be modified for TrFO (AoIP), then the oMSC can utilize Assignment (modify) or 
Internal Handover Enquiry before sending LCLS_CONNECT_CONTROL message. 

27a. Since the ESS has received the through connect request for both call legs the oBSS returns the 

LCLS_CONNECT_CONTROL_ACK message with the LCLS -BSS -Status IE set to "the call is locally 
switched with requested LCLS configuration" . 

27b. Since the BSS has received the through connect request for both call legs the tBSS signals the LCLS status 
change by sending the LCLS_NOTIFICATION message with the LCLS -BSS -Status IE set to "the call is 
locally switched with requested LCLS configuration" . 

28. The oMSC server signals the change of the LCLS status through the Core Network by sending the APM 
message with the LCLS-Status IE set to "LCLS connected". 

29. The iMSC server transfers the change of the LCLS status to the tMSC server. 

13.4.3 Call Forwarding on mobile subscriber Busy (CFB) 
13.4.3.1 Network Determined User Busy (NDUB) 

13.4.3.1.1 General 

The incoming call that meets mobile subscriber busy with the condition Network Determined User Busy (NDUB) shall 
be forwarded towards the forwarded-to subscriber without being offered to the served mobile subscriber. The basic call 
establishment procedures defined in the clause 6 shall be followed for the call towards the forwarded-to subscriber. 

13.4.3.1.2 Notification to the Calling Subscriber 

If the GMSC server determines that a call should be forwarded without being offered to the served mobile subscriber 
and the served mobile subscriber has requested that the calling subscriber shall receive a notification about the call 
forwarding, the GMSC server shall send a notification to the preceding node. If the GMSC server supports the LCLS 
feature and receives the GCR IE, the LCLS -Negotiation Request IE and LCLS -Configuration-Preference IE from the 
preceding node it may modify the LCLS -Configuration-Preference IE based on its own LCLS configuration 
requirements, as described in sub-clause 4.2, and it shall return the resulting LCLS -Configuration-Preference IE and the 
LCLS -Negotiation Response IE to the preceding node. 

If the notification is implemented using intermediate tones or announcements the GMSC server requests the MGW to 
play an announcement/tone to the calling party, as described in sub-clause 14.6, before establishing the call to the 
forwarded-to subscriber. 

13.4.3.1.3 Initial Addressing 

If the incoming call is to be forwarded without being offered to the served mobile subscriber the call towards the 
forwarded-to subscriber is established as for a basic call. After the possible generation of in-band information has been 
completed the initial addressing towards the forwarded-to subscriber is performed as described in the clause 6 for the 
basic mobile terminating call. If the GMSC server supports the LCLS feature and receives the GCR IE, the LCLS- 
Negotiation Request IE and LCLS -Configuration-Preference IE from a preceding node in the I AM it shall forward the 
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GCR IE and the resulting LCLS -Configuration-Preference IE and the LCLS -Negotiation Request IE to the succeeding 
node. 

13.4.3.1 .4 Backward LCLS Negotiation 

The procedure specified in sub-clause 6.2.1.2.2 for the intermediate node and in sub-clause 6.1.1.4 for the oMSC server 
shall be applied. 

1 3.4.3.1 .5 LCLS Through-Connection 

The procedure specified in sub-clause 6.1.1.5 shall be applied. 

13.4.3.1.6 Example 

The same example as for Call Forwarding Unconditional applies. 

1 3.4.3.2 User Deternnined User Busy (UDUB) 

13.4.3.2.1 General 

The incoming call shall be offered to the served subscriber as a normal call. When the call meets mobile subscriber busy 
with the condition User Determined User Busy (UDUB) it shall be forwarded towards the forwarded-to subscriber. The 
basic call establishment procedures defined in the clause 6 shall be followed for the call towards the forwarded-to 
subscriber. 

1 3.4.3.2.2 Call Clearing to the Served Subscriber 

When the MSC server determines that the call shall be forwarded due to the UDUB it shall release the call leg towards 
the served subscriber as described in the sub-clause 7.1 for call clearing. 

1 3.4.3.2.3 Notification to the Calling Subscriber 

If the MSC server determines that a call should be forwarded and the served mobile subscriber has requested that the 
calling subscriber shall receive a notification about the call forwarding, the MSC server shall send a notification to the 
preceding node. 

If the notification is implemented using intermediate tones or announcements the MSC server requests the MGW to 
play an announcement/tone to the calling party, as described in sub-clause 14.6, before establishing the call to the 
forwarded-to subscriber. 

1 3.4.3.2.4 Initial Addressing 

If the incoming call is to be forwarded the call towards the forwarded-to subscriber is established as for a basic call. 
After the possible generation of in-band information has been completed the initial addressing towards the forwarded-to 
subscriber is performed as described in the clause 6 for the basic mobile terminating call. If the forwarding MSC server 
supports the LCLS feature and has received the GCR IE, the LCLS -Negotiation Request IE and LCLS -Configuration- 
Preference IE from a preceding node in the I AM it shall then forward the GCR IE and the resulting LCLS- 
Configuration-Preference IE and the LCLS -Negotiation Request IE to the succeeding node. 

NOTE: If LCLS has been successfully negotiated to this point the oMSC have received back the LCLS- 

Negotiation Response IE and LCLS -Configuration-Preference IE and LCLS Status may have indicated 
that the call can be locally switched but since the called subscriber did not answer the call is still switched 
through the CN at this point. 

1 3.4.3.2.5 Backward LCLS Negotiation 

The procedure specified in sub-clause 6.2.1.2.2 for the intermediate node and in sub-clause 6.1.1.4 for the oMSC server 
shall be applied. 
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1 3.4.3.1 .6 LCLS Through-Connection 

The procedure specified in sub-clause 6.1.1.5 shall be applied. 



13.4.3.2.7 
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13.4.3.2.7.1 
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Figure 13.4.3.2.7.1.1 shows the network model for call forwarding busy UDUB. 

The oMSC server seizes one context with two bearer terminations in the oMGW. The bearer termination Tl is used for 
the bearer towards the oBSS (calling subscriber) and the bearer termination T2 is used for the bearer towards the GMSC 
selected iMGW. The GMSC server seizes one context with two bearer terminations in the iMGW. The bearer 
termination T4 is used for the bearer towards the sMSC server selected sMGW and the bearer termination T3 is used for 
the bearer towards the preceding oMGW. The sMSC server seizes one context with two bearer terminations in the 
sMGW. The bearer termination T5 is used for the bearer towards the GMSC selected iMGW and bearer termination Ts 
is used for the bearer towards the sBSS (served subscriber). 

After call forwarding busy UDUB is detected the sMSC server replaces the bearer termination for the served mobile 
subscriber Ts with the bearer termination for the forwarded-to subscriber T6 in an existing context in the sMGW. 

The tMSC server seizes one context with two bearer terminations in the tMGW. The bearer termination T7 is used for 
the bearer towards the sMSC selected sMGW and bearer termination T8 is used for the bearer towards the tBSS 
(forwarded-to subscriber). 
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13.4.3.2.7.2 



Connection Model 3: CFB (UDUB), After Answer, Call locally switched 
Figure 13.4.3.2.7.1.1: Connection Model for Call Forwarding Busy UDUB 

Basic Sequence 



Figure 13.4.3.2.7.2.1 shows the message sequence example for the call forwarding UDUB with a possible notification 
to the calHng party using an announcement. In the example the sMSC server optionally requests the sMGW to play an 
announcement and to notify the announcement completion, after the bearer to the incoming side has been established. 
When the possible announcement has completed the sMSC server requests the establishment of the call and the bearer 
towards the forward-to subscriber. This example is based on examples from clause 6. 
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For call establishment towards served subscriber sUE see basic call establishment, figures 6.3.2.1 and 6.3.2.2 
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13. For succeeding signalling sequence see Call Forwarding Unconditional, figure 13.4.2.5.2.2 steps 23 -29. 



Figure 13.4.3.2.7.2.1: CFB UDUB, Call establishment flow 
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1. The sMSC server determines that call should be forwarded because of the Call Forwarding Busy UDUB 
supplementary service and that notification should be send towards the calling party (oUE). 

2. The sMSC server orders the sMGW to remove the bearer termination (Ts) towards the served mobile 
subscriber (in case when the radio resources had already been allocated in the sMGW). 

3. The sMSC server sends the CPG message with the Generic Notification Indicator parameter set to "Call is 
diverting". 

4. The sMSC server provides the sMGW with the announcement/tone identification and requests the sMGW to 
notify the announcement/tone completion using the Play Announcement or Send Tone procedure. 

5. The GMSC server sends the CPG message with the Generic Notification Indicator parameter set to "Call is 
diverting". 

6. The oMSC server notifies the calling user (oUE) about call forwarding. 

7. The sMGW notifies the sMSC server when the announcement/tone is completed using the Announcement 
Completed or Tone Completed procedure. 

8. If the sMSC server supports LCLS it may modify the LCLS -Negotiation IE before sending the lAM message 
containing the GCR with the encapsulated oBSS ID and the LCLS -Negotiation IE. 

9. When performing further call establishment towards the forwarded-to subscriber see clause 6 and the 
procedure specified for mobile originating call. 

10. The tMSC server returns the APM message with the selected codec and if LCLS is supported, the LCLS- 
Negotiation IE. 

11. The sMSC server transfers the APM message with the LCLS -Negotiation IE. If codec modification is 
required then the sMSC server includes the codec related information within the same APM message. 

12. The GMSC server transfers the APM message. 

13. When performing further call establishment see signalling sequence for Call Forwarding Unconditional, 
figure 13.4.2.5.2.2, steps 23 -29. 

13.4.4 Call Forwarding on No Reply (CFNRy) 

13.4.4.1 General 

The incoming call shall be offered to the served subscriber as a normal call. When the Call Forwarding on No Reply 
(CFNRy) supplementary service is active and if the call is not answered within the period of time defined by the no 
reply condition timer it shall be forwarded towards the forwarded-to subscriber. The basic call establishment procedures 
defined in the clause 6 shall be followed for the call towards the forwarded-to subscriber. 

13.4.4.2 Call Clearing to the Served Subscriber 

When the MSC server determines that the call shall be forwarded due to the CFNRy it shall release the call leg towards 
the served subscriber as described in the sub-clause 7.1 for call clearing. 

1 3.4.4.3 Notification to the Calling Subscriber 

If the MSC server determines that a call should be forwarded and the served mobile subscriber has requested that the 
calling subscriber shall receive a notification about the call forwarding, the MSC server shall send a notification to the 
preceding node. 

If the notification is implemented using intermediate tones or announcements the MSC server requests the MGW to 
play an announcement/tone to the calling party, as described in sub-clause 14.6, before establishing the call to the 
forwarded-to subscriber. 
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13.4.4.4 Initial Addressing 

If the incoming call is to be forwarded the call towards the forwarded-to subscriber is established as for a basic call. 
After the possible generation of in-band information has been completed the initial addressing towards the forwarded-to 
subscriber is performed as described in the clause 6 for the basic mobile terminating call. If the MSC server supports the 
LCLS feature and has received the GCR IE, the LCLS -Negotiation Request IE and LCLS -Configuration-Preference IE 
from a preceding node in the I AM it shall then forward the GCR IE and the resulting LCLS -Configuration-Preference 
IE and the LCLS -Negotiation Request IE to the succeeding node. 

13.4.4.5 Backward LCLS Negotiation 

The procedure specified in sub-clause 6.2. L2. 2 for the intermediate node and in sub-clause 6.L1.4 for the oMSC server 
shall be applied. 

1 3.4.4.6 LCLS Through-Connection 

The procedure specified in sub-clause 6.LL5 shall be applied. 

13.4.4.7 Example 



13.4.4.7.1 



Connection Model 



Figure 13.4.4.7. LI shows the network model for Call Forwarding on No Reply (CFNRy). 

The oMSC server seizes one context with two bearer terminations in the oMGW. The bearer termination Tl is used for 
the bearer towards the oBSS (calling subscriber) and the bearer termination T2 is used for the bearer towards the GMSC 
selected iMGW. The GMSC server seizes one context with two bearer terminations in the iMGW. The bearer 
termination T4 is used for the bearer towards the sMSC server selected sMGW and the bearer termination T3 is used for 
the bearer towards the preceding oMGW. The sMSC server seizes one context with two bearer terminations in the 
sMGW. The bearer termination T5 is used for the bearer towards the GMSC selected iMGW and bearer termination Ts 
is used for the bearer towards the sBSS (served subscriber). 

After Call Forwarding on No Reply is detected the sMSC server replaces the bearer termination for the served mobile 
subscriber Ts with the bearer termination for the forwarded-to subscriber T6 in an existing context in the sMGW. 

The tMSC server seizes one context with two bearer terminations in the tMGW. The bearer termination T7 is used for 
the bearer towards the sMSC selected sMGW and bearer termination T8 is used for the bearer towards the tBSS 
(forwarded-to subscriber). 
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User plane link which transmits real user plane data within BSS and UEs 

User plane link which transmits real user plane data in backward direction 
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Connection Model 1: Before CFNRy 
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oUE 



Control 
Signalling 




Connection Model 2: After CFNRy, Announcement towards calling party 



tUE 



oUE 



Control 
Signalling 




13.4.4.7.2 



Connection Model 3: CFNRy, After Answer, Call locally switched 
Figure 13.4.4.7.1.1: Connection Model for Call Forwarding on No Reply 

Basic Sequence 



Figure 13.4.4.7.2.1 shows the message sequence example for the Call Forwarding on No Reply with a possible 
notification to the calling party using an announcement. In the example the sMSC server optionally requests the sMGW 
to play an announcement and to notify the announcement completion, after the bearer to the incoming side has been 
established. When the possible announcement has completed the sMSC server requests the establishment of the call and 
the bearer towards the forward-to subscriber. This example is based on examples from clause 6. 
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oUE 



oBSS 



oMGW 



oMSC 



iMGW 
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sMSC 



sMGW 



tMSC 



tUE 



For call establishment towards served subscriber sUE see basic call establishment, figures 6.3.2.1 and 6.3.2.2 



6. R\CILITYwithcal 
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Context (sC) 
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■ Announcement / Tone- 



12. ARM [S 



10. ARM [S 
11. ARM [SCt, ACLt, |_CLS-Negotiation] 
;t, ACLt, LCLS-Negotiation] 



Context (sC) 



Context (sC) 



2. Release te 
SUB request 



mination to served UE: 
(Ts)/ SUB reply (Ts) 



4. MOD (T5): 



announcement / send tone 



8. lAM [Code 



play 



7. NOTIFY (T5): Announcerjnent / 
Tone compleied 



: List, GCR, LCLS-Negotiatic 



n] 



9. For call establishment towards forwarded-to 

subscriber tUE see basic call establishment, figure 

6.3.2.1 



t, ACLt, LCLS-Negotiation] 



13. For succeeding signalling sequence see Call Forwarding Unconditional, figure 13.4.2.5.2.2 steps 23 -29. 



Figure 1 3.4.4.7.2.1 : CFNRy, Call establishment flow 

1 . The sMSC server determines that call should be forwarded because of the Call Forwarding on No Reply 
supplementary service and that notification should be send towards the calling party (oUE). 

2. The sMSC server orders the sMGW to remove the bearer termination (Ts) towards the served mobile 
subscriber (in case when the radio resources had already been allocated in the sMGW). 

3. The sMSC server sends the CPG message with the Generic Notification Indicator parameter set to "Call is 
diverting". 

4. The sMSC server provides the sMGW with the announcement/tone identification and requests the sMGW to 
notify the announcement/tone completion using the Play Announcement or Send Tone procedure. 

5. The GMSC server sends the CPG message with the Generic Notification Indicator parameter set to "Call is 
diverting". 

6. The oMSC server notifies the calling user (oUE) about call forwarding. 

7. The sMGW notifies the sMSC server when the announcement/tone is completed using the Announcement 
Completed or Tone Completed procedure. 

8. If the sMSC server supports LCLS it may modify the LCLS-Negotiation IE before sending the lAM message 
containing the GCR with the encapsulated oBSS ID and the LCLS-Negotiation IE. 

9. When performing further call establishment towards the forwarded-to subscriber see clause 6, the procedure 
specified for mobile originating call. 

10. The tMSC server returns the APM message with the selected codec and if LCLS is supported, the LCLS- 
Negotiation IE. 
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11. The sMSC server transfers the APM message with the LCLS -Negotiation IE. If codec modification is 
required then the sMSC server includes the codec related information within the same APM message. 

12. The GMSC server transfers the APM message. 

13. When performing further call establishment see signalling sequence for Call Forwarding Unconditional, 
figure 13.4.2.5.2.2, steps 23 -29. 

13.4.5 Call Forwarding on mobile subscriber Not Reachable (CFNRc) 

13.4.5.1 General 

The incoming call that meets mobile subscriber unreachable shall be forwarded towards the forwarded-to subscriber 
without being offered to the served mobile subscriber. The basic call establishment procedures defined in the clause 6 
shall be followed for the call towards the forwarded-to subscriber. 

1 3.4.5.2 Rerouting by HLR 

The same handling as for Call Forwarding Unconditional applies. 

13.4.5.3 Rerouting by VLB 

The same handling as for Call Forwarding Unconditional applies. 

13.5 Call Waiting (CW) 

13.5.1 Principles 

The procedures specified for the Call Waiting supplementary service in 3GPP TS 23.205 [2] sub-clause 13.6 for BICC 
based CS Core Network and in 3GPP TS 23.231 [3] sub-clause 13.6 for SIP-I based CS Core Network shall be followed 
with the following modifications: 

- The call establishment and call clearing procedures defined in clauses 6 and 7 shall be applied. 

- If the new call is accepted, the GCR of the new call is sent to the BSS in the ASSIGNMENT procedure 

The following sub-clauses describe the additional requirements related to the LCLS functionality when the Call Waiting 
supplementary service is activated for the locally switched call. 

13.5.2 Accept the new incoming call, the original call is hold 

13.5.2.1 General 

When new call arrives and is accepted, the GCR and LCLS -Configuration of the local access bearer shall be modified 
according to the new call. The MSC Server shall initiate an ASSIGNMENT REQUEST message towards the BSS 
including the GCR and LCLS -Configuration of the new call. 

13.5.2.2 Example 
13.5.2.2.1 Connection Model 

Figure 13.5.2.2. LI shows the network model for Call Waiting supplementary service of holding the original call to 
accept the new call. Termination Ti to Tg is established for original call between UE-A and UE-B. When UE-A and UE- 
B have an active call established, UE-C, which is roaming under BSS-B and MSC-B, initiates a new call towards UE-A. 
To accept the new call, UE-A holds the call with UE-B and relocates its access bearer for the new call. 

After the new call between UE-C and UE-A is established, a new context (CI -2) is seized in MGW-A. The access 
bearer termination Tg is moved from CI to CI -2 and a new network bearer towards the iMGW is created (T7). In the 
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iMGW, a new context (iC-2) is created with terminations for the bearers with MGW-A (Tg) and with MGW-B (T9). In 
MGW-B, new terminations are created for the access bearer towards UE-C (Tn) and for bearer towards iMGW (Tio). 
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Connection Model 1: Before new call incoming 



UE-A 
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MGW-B 
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MGW-A 



Connection Model 2: Incoming call is established, UE-B held, Announcement towards UE-B 
Figure 13.5.2.2.1.1 : Connection Model for Accept Incoming call, original call is held 



13.5.2.2.2 



Basic Sequence 



Figure 13.5.2.2.2.1 shows the message sequence example for the acceptance of new call and hold the original one. The 
ASSIGNMENT REQUEST message is sent from MSC-A to BSS-A to update the GCR stored within the BSS-A. 
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6.SETUP 
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Negotiation] 



ISErUP 



2. CALL PROCEEDING 



8. normal LCLS call establishment procedure between UE-A and UE-C from step 8 to 17 in 6.3.2 



9. Hold Request 



10. The session between UE-A and UE-B is put on hold 



II.HoldAck 



12. Connec: 



' 3. Move acce: 
MOV request (' 



s side terminatipn 
"6) / MOV reply 



:T6)Context(C1-2) 



14. normal LCLS call establishment procedure between UE-A and UE-C from step 19 in 6.3.2, skipping step 21,22,23 24. 




Call is locally Sw tched 



Figure 13.5.2.2.2.1: Accept Incoming call, original call is held 

UE-C sends a SETUP message to the Core Network. 

MSC-B responds with CALL PROCEEDING message. 

MSC-B sends the lAM message including supported codecs Hst, GCR with encapsulated BSS-B ID and 
LCLS-Negotiation IE. 

iMSC transfers the lAM message to MSC-A. 

MSC-A determines that UE-A is busy and that call waiting is available. 

MSC-A sends a SETUP message to UE-A. 

UE-A responds with CALL CONFIRM message. 

The normal LCLS call establishment procedures from step 8 to 17 in 6.3.2 are applied. 

UE-A requests to hold the call with UE-B. 
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10. The session between UE-A and UE-B is put on hold. The procedure in 13.6.2.3.2 is applied. 

11. After the session between UE-A and UE-B is put on hold, MSC-A sends the acknowledgement to UE-A. 

12. UE-A accepts the incoming call by sending CONNECT message to MSC-A. 

13. MSC-A requests the MGW to move the termination T6 to the context of incoming call (CI -2). 

14. The normal LCLS call establishment procedures from step 19 in 6.3.2 are applied, skipping step 21, 22 a, 
22b, 23 and 24. BSS-A shall update the GCR and the LCLS -Configuration on receipt of the ASSIGNMENT 
REQUEST message for the access bearer. 

13.6 Call Hold (CH) 

13.6.1 Principles 

The procedures specified for the Call Hold supplementary service in 3GPP TS 23.205 [2] sub-clause 13.6 for BICC 
based CS Core Network and in 3GPP TS 23.231 [3] sub-clause 13.6 for SIP-I based CS Core Network shall be followed 
with the following modifications: 

- The call establishment and call clearing procedures defined in clauses 6 and 7 shall be applied. 

- If a new call is established after the original call is held, the MSC shall generate a new GCR for the new call. 

The following sub-clauses describe the additional requirements related to the LCLS functionality when the Call Hold 
supplementary service is activated for the locally switched call. 

13.6.2 Call Hold after Answer, LCLS established 

13.6.2.1 Hold Request 

When the UE makes a request for the hold function for the locally switched call the MSC server shall request a LCLS 
break procedure described in sub-clause 7.2.1. 

The MSC server shall request the MGW to interrupt the communication on the bearer by changing the through- 
connection of the bearer termination towards the served mobile subscriber to "inactive" or by using the Isolate Bearer 
Termination Procedure. 

If an announcement is to be applied to the held party the MSC shall apply the procedure for non LCLS call defined in 
3GPP TS 23.205 [2] sub-clause 14.6 for BICC based CS Core Network and in 3GPP TS 23.231 [3] sub-clause 14.6 for 
SIP-I based CS Core Network. 

If a handover occurs to the UE making the request for the hold function (UE-A) while the party is not intended to be re- 
connected locally then the MSC Server shall include LCLS -Connection-Status-Control set to "do not establish LCLS" 
in the HO Request message. 

13.6.2.2 Retrieval Request 

When the UE makes a request to retrieve a held call the MSC server shall stop an announcement that was applied to the 
held party. The MSC shall request the MGW to re-establish communication to the held party by changing the through- 
connection of the bearer termination towards the served mobile subscriber to be both- way through-connected or by 
using the Join Bearer Termination Procedure. 

If the call has been successfully negotiated for LCLS and an LCLS break was triggered by the CN the MSC server shall 
perform a LCLS re-establishment as described in sub-clause 7.3.1. 

NOTE: LCLS re-negotiation can occur while the call is on hold or the held call is connected to a new party (ECT) 
which may change the LCLS configuration and thus permit or prevent LCLS. 
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13.6.2.3 Example 



13.6.2.3.1 



Connection Model 



Figure 13.6.2.3.1.1 shows the network model for Call Hold supplementary service when LCLS was established. The 
MSC-B server seizes one context with two bearer terminations in the MGW-B. The bearer termination Tl is used for 
the bearer towards the BSS-B and the bearer termination T2 is used for the bearer towards the iMSC selected iMGW. 
The iMSC server seizes one context with two bearer terminations in the iMGW. The bearer termination T4 is used for 
the bearer towards the MSC-A server selected MGW-A and the bearer termination T3 is used for the bearer towards the 
preceding MGW-B. The MSC-A server seizes one context with two bearer terminations in the MGW-A. The bearer 
termination T5 is used for the bearer towards the iMSC selected iMGW and bearer termination T6 is used for the bearer 
towards the BSS-A. 
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Connection Model 1: Before Call Hold, LCLS established and 
Connection Model 3: After Retrieval procedure, LCLS established 
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Connection Model 2: After Hold procedure, LCLS released; Announcement towards held party 
Figure 1 3.6.2.3.1 .1 : Connection Model for Call Hold 
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13.6.2.3.2 



Basic Sequence 



Figure 13.6.2.3.2.1 shows the message sequence example for the Hold procedure with a possible notification to the held 
party using an announcement. In the example the MSC server requests the MGW to play an announcement towards the 
held party. 



UE-B 



BSS-B 



MGW-B 



MSC-B 



iMGW 



Call 



iMSC 



is locally Switched 




For LCLS release procedure initiated by IVISC server see the corresponding signalling sequence in sub-clause 7.2.1 



7. FACIL TY with call held notification 



ORG [Geneijic 
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5. CPG [Gleneri 
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Notification 
remote hold"] 



■ Announcement- 



Context (tC) 

ic Notification 
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Context (tC) 



4. MOD request (T6): inactije / 
MOD reply , 



8. HOLDACK 



9. MOD request 
announcement 



NOWLEDGE 



(T5): Play 
/ MOD reply 



Figure 13.6.2.3.2.1 : Hold Request on LCLS call 

1 . HOLD message is received from the UE- A. 

2. The MSC- A server accepts the HOLD request. 

3. The MSC-A server requests a LCLS break procedure described in sub-clause 7.2. L 

4. The MSC-A server requests the MGW- A to interrupt the communication on the bearer by changing the 
through-connection of the bearer termination towards the UE-A to "inactive". 

5. The MSC-A server sends the CPG message with the Generic Notification Indicator parameter set to "remote 
hold" to the iMSC. 

6. The iMSC server transfers the CPG message to the MSC-B server. 

7. The MSC-B server sends FACILITY message with the call hold notification to the UE-B. 

8. The MSC-A server informs the UE-A that call hold is accepted with the HOLD ACKNOWLEDGE message. 

9. The MSC-A server requests the MGW- A to play an announcement towards the held party. 
Figure 13.6.2.3.2.2 shows the message sequence for the Retrieval procedure. 
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For LCLS re-establishment procedure initiated by MSC server see the corresponding signalling sequence in sub-clause 7.3.1 




Ca I is locally SiA^itched 




Figure 13.6.2.3.2.2: Retrieval Request and LCLS re-establishment 

1 . RETRIEVE message is received from the UE-A. 

2. The MSC-A server accepts the RETRIEVE request. 

3. The MSC-A server requests the MGW-A to stop an announcement towards the held party. 

4. The MSC-A server requests the MGW-A to re-estabHsh communication to the held party by changing the 
through-connection of the bearer termination towards the UE-A to be both- way through-connected. 

5. The MSC-A server sends the CPG message with the Generic Notification Indicator parameter set to "remote 
retrieval" to the iMSC. 

6. The iMSC server transfers the CPG message to the MSC-B server. 

7. The MSC-B server sends FACILITY message with the call hold notification to the UE-B. 

8. The MSC-A server informs the UE-A that retrieve request is accepted with the RETRIEVE 
ACKNOWLEDGE message. 

9. If the call has been successfully negotiated for LCLS the MSC-A server requests a LCLS re-establishment 
procedure as described in sub-clause 7.3. L 

13.6.3 Call Hold after Answer, LCLS not established 
13.6.3.1 Hold Request 

When the UE makes a request for the hold function for the non-local call the MSC server shall signal LCLS- 
C0NNECT_C0NTR0L message with LCLS -Connection-status-control set to "do not establish LCLS". 
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NOTE: this is to avoid the case that the party requesting hold (which is no longer intended to be connected to the 
held party) performs a handover into the same BSS and triggers local switching in the BSS. 

13.6.3.2 Retrieval Request 

When the UE makes a request to retrieve a held call the MSC server shall stop an announcement that was applied to the 
held party. The MSC shall request the MGW to re-establish communication to the held party by changing the through- 
connection of the bearer termination towards the served mobile subscriber to be both- way through-connected or by 
using the Join Bearer Termination Procedure. 

If the call has been successfully negotiated for LCLS then MSC server shall signal LCLS-CONNECT_CONTROL 
message with LCLS-Connection-status-control set to "connect". If the BSS established local switching it shall notify the 
core network. 

13.6.4 Establishment of a new call, the original call is hold 

13.6.4.1 General Principle 

The call hold procedures and call establishment procedures shall be applied with the following enhancements. 

To avoid the local switching between remote parties of the new call and the held call, the new call shall have a different 
GCR than the GCR of the original call. During the new call establishment, the MSC server serving the UE which has 
the held call and has initiated the new call shall generate a new GCR for the new call. 

The MSC server shall use the ASSIGNMENT REQUEST message to update the BSS serving the UE which has the 
held call and has initiated the new call with the new GCR and LCLS -Configuration for the new call. 

The access bearer is kept unchanged. 

13.6.4.2 Assignment Request 

During the new call establishment, the MSC server serving the UE which has the held call and has initiated the new call 
shall send the Assignment Request message to update the BSS with the new GCR and LCLS -Configuration for the new 
call. 

On receipt of Assignment Request, the BSS shall save the GCR and LCLS -Configuration in this message. 

13.6.5 Retrieval of the held call, ongoing call is on-hold/completed 
13.6.5.1 General Principle 

When the UE requests to place the new call on hold and retrieve the original call, the MSC server shall initiate normal 
call hold procedures as described in sub-clause 13.6.1 for the new call. The MSC server sends the ASSIGNMENT 
REQUEST message with the GCR and LCLS -Configuration of the original call to the BSS. The MSC server continues 
the retrieval procedure as described in sub-clause 13.6.2.2. 

When the UE requests to retrieve the original call after the active session has completed, the MSC server shall send the 
ASSIGMENT REQUEST message to the BSS to update the GCR and LCLS -Configuration for the original call. The 
MSC server continues the retrieval procedures as described in sub-clause 13.6.2.2. 
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13.6.5.2 Example call flow, Retrieval of held call after ongoing call has completed 
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Figure 13.6.5.2.1: Retrieval of held call, ongoing call has completed 

The active session between UE-A and UE-C is released. 

The RETRIEVE message is sent from UE-A to MSC-A Server. 

MSC-A server accepts the RETRIEVE request. 

MSC-A server retrieves the LCLS -Configuration and GCR for the held session and sends the 
ASSIGNMENT REQUEST message to BSS-A including the LCLS -Configuration IE and the GCR IE. 

The BSS-A returns the ASSIGNMENT COMPLETE message with the LCLS -BSS -Status IE indicating "call 
not possible to be locally switched". 

MSC-A server continues the sequence handling described in sub-clause 13.6.2.3.2. 



13.7 Multiparty (MPTY) 

If LCLS is established for a call it shall be released while the Multiparty (MPTY) service is utilised, see LCLS break 
procedure in clause 7.2 of this specification. After MPTY is ended LCLS may be re-established if it is still feasible, see 
LCLS re-establishment procedure in clause 7.3 of this specification. 

1 3.8 Closed User Group (CUG) 

No impact. There are no LCLS related requirements for the Closed User Group (CUG) service. 

1 3.9 Advice of Charge (AoC) 

No impact. There are no LCLS related requirements for the Advice of Charge (AoC) service. 

13.10 User-to-User Signalling (UUS) 

No impact. There are no LCLS related requirements for the User-to-User Signalling (UUS) service. 

13.11 Call Barring Services 

No impact. There are no LCLS related requirements for the Call Barring Services. 
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13.12 Explicit Call Transfer (ECT) 



In order to perform Explicit Call Transfer, if LCLS is established for the first call this will be broken when it is put on 
hold as per the procedures specified in sub-clause 13.6. If LCLS is established for the second call then the local 
switching of the call shall be released in order to be connected to the held party. 

Procedures to establish LCLS for the transferred call are not supported. 

13.13 Completion of Calls to Busy Subscriber (CCBS) 

No impact. There are no LCLS related requirements for the Completion of Calls to Busy Subscriber (CCBS) service. 

13.14 Multiple Subscriber Profile (MSP) 

No impact. There are no LCLS related requirements for the Multiple Subscriber Profile (MSP) service. 

13.15 Multicall 

There are no specific LCLS related requirements for the Multicall service. 

NOTE: If LCLS is established for any call as part of the Multicall service, then the local switching of the call will 
be released when it is put on hold as per the procedures specified in sub-clause 13.6. 

13.16 Calling Name Presentation (CNAP) 

No impact. There are no LCLS related requirements for the Calling Name Presentation (CNAP) service. 

13.17 Alternate Speech/Fax 

LCLS shall not be allowed for the Alternate Speech/Fax calls. 

13.18 Modification of the Access Bearer 

During the call establishment phase, the modification of the access bearer procedure shall be performed in accordance 
with 3GPP 23.205 [2] for a BICC based CS core network and in accordance with 3GPP TS 23.231 [3] for a SIP-I based 
CS core network. 

When the call is locally switched, if the MSC Server requires modification of the access bearer, an LCLS Break 
procedure as specified in sub-clause 7.2.1 may occur. 

13.19 GSM Fax 

LCLS shall not be allowed for the GSM Fax calls. 

13.20 Voice group call service (VGCS), Voice broadcast service 
(VBS) 

LCLS shall not be allowed when the Voice group call service (VGCS) or the Voice broadcast service (VBS) is utilised. 
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14 Interactions with Other Network Features and 
Services 

14.1 Customised Applications for Mobile network Enhanced 
Logic (CAMEL) 

No impact. There are no LCLS related requirements for Customised Applications for Mobile network Enhanced logic 
(CAMEL). 

If LCLS is established for the call and a CAMEL service requires the insertion of Tones/ Announcements, the LCLS 
procedures for Providing Tones or Announcements shall be applied as specified in sub-clause 14.6. 

If LCLS is established for the call and a CAMEL service requires the user-plane to be manipulated within the Core 
Network, the LCLS procedures for breaking LCLS shall be applied as specified in sub-clause 7.2. 

14.2 1ST 

No impact. There are no LCLS related requirements for Immediate Service Termination (1ST). 

14.3 Operator Determined Barring (ODB) 

No impact. There are no LCLS related requirements for Operator Determined Barring (ODB). 

14.4 DTMF 

No impact. There are no LCLS related requirements for DTMF. 

If LCLS is established for the call and a DTMF tone is required to be sent to the UE, the LCLS procedures for 
Providing Tones or Announcements shall be applied as specified in sub-clause 14.6. 

14.5 OR 

No impact. There are no LCLS related requirements for Optimal Routing (OR). 

14.6 Providing tones or announcements 
14.6.1 General 

Tones or announcements may be applied at any time during the call establishment or mid-call. Also periodic tones may 
be applied during the call. Prior to answer, an LCLS compatible call is still connected through the core network and so 
any tones or announcements applied at this time are handled as for normal non-LCLS calls. 

If a node wishes to apply periodic tones during the call it may either reject the LCLS entirely or may indicate that it 
requires send access in a certain direction. This is achieved during the LCLS negotiation phase as described in sub- 
clause 4.2. 

If the call is established and local switching is performed and at a later point in the call a (G)MSC Server needs to send 
a tone or announcement there are two options it may apply: 

- perform a (G)MSC initiated LCLS break as described in sub-clause 7.2.1 and once the LCLS break is complete 
then begin applying the tone or announcement, or 

- request temporary send access to the user plane as described in 14.6.2 
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If a node (subsequent CN node or BSS) does not support the procedures described for requesting temporary send access 
then a full LCLS break shall occur. 

14.6.2 Handling of tones or announcements during an LCLS call 

14.6.2.1 GMSC Server or internnediate node requiring temporary send access to apply 
tone or announcement 

A GMSC Server or intermediate node wishing to insert a tone or announcement may signal LCLS Configuration 
Change Request message with LCLS Configuration Preference IE setting "Need Send Backward = yes" if it needs to 
insert a tone or announcement towards the originating subscriber or "Need Send Forward = yes" if it needs to insert a 
tone or announcement towards the terminating subscriber. 

NOTE: The (G)MSC Server or intermediate node only needs to signal the LCLS Configuration Change Request 
message in the direction in which it wishes to apply the tone or announcement. The other LCLS 
Configuration Preference IE settings remain unchanged. 

If the (G)MSC receives the LCLS -Configuration Change Request Acknowledge message with LCLS Configuration 
Change Result IE indicating acceptance of the requested LCLS Configuration change it shall proceed to insert its tone 
or announcement as per a normal call handling. 

Otherwise, if the received LCLS Configuration Change Result IE indicates the requested LCLS Configuration change is 
rejected, the (G)MSC Server shall perform an intermediate node initiated LCLS break as described in sub-clause 7.2.3 
and when the LCLS break is complete shall apply the tone or announcement. On the completion of the tone or 
announcement if LCLS break occurred the LCLS may be re-established as described in sub-clause 7.3.3. 

On completion of the tone or announcement if LCLS break was not required the (G)MSC Server may signal LCLS- 
Configuration Change Request message with LCLS Configuration Preferences IE indicating "Need Send Backward= 
no" or "Need Send Forward = no" towards preceding/succeeding node respectively. 

The appropriate LCLS configurations which result from the new LCLS Configuration preference settings are specified 
in Table 4.2. LL 

14.6.2.2 oMSC Server 

An oMSC Server wishing to insert a tone or announcement towards the terminating UE may signal LCLS Configuration 
Change Request message with LCLS Configuration Preference IE set to "Need Send Forward = yes". 

NOTE: The other LCLS -Configuration Preference settings remain unchanged. 

If the oMSC Server receives the LCLS- Configuration Change Request Acknowledge message with a LCLS 
Configuration Change Result IE indicating acceptance of the requested LCLS Configuration change then it shall 
proceed to insert its tone or announcement as per a normal call handling. Otherwise, if the received LCLS 
Configuration Change Result IE indicates the requested LCLS configuration change is rejected, the oMSC Server shall 
perform a MSC initiated LCLS break as described in sub-clause 7.2.1 and once the LCLS break is complete then begin 
applying the tone or announcement. On the completion of the tone or announcement LCLS may be re-established as 
described in sub-clause 7.3. L 

On completion of the tone or announcement (without LCLS Break) in the forward direction the oMSC Server may 
signal the LCLS -Configuration Change Request message to succeeding node indicating "Need Send Forward = no". 

If the oMSC Server wishes to insert a tone or announcement only towards its locally served UE it does not need to 
request any change to the LCLS configuration preferences in the Core Network and may send the LCLS-Connect- 
Control message to the oBSS containing the appropriate LCLS -Configuration IE settings as specified in Table 4.2. LI 
and if supported by the oBSS, the oMSC, oMGW shall begin applying the tone or announcement. On completion of the 
tone or announcement the oMSC shall return the LCLS Configuration to the previous setting. 

If the oMSC Server receives LCLS -BSS -Status indicating that the oBSS does not support the requested LCLS- 
Configuration then the oMSC Server shall initiate LCLS Break towards the oBSS and succeeding node, as described in 
sub-clause 7.2. L On completion of the tone or announcement after LCLS Break LCLS may be re-established as 
described in sub-clause 7.3. L 
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If the oMSC Server receives the LCLS- Configuration Change Request message with LCLS -Configuration Preference 
IE indicating "Need Send Backward^ yes" it shall send LCLS-Connect-Control message containing the appropriate 
LCLS -Configuration IE settings as specified in Table 4.2. LI and if supported by the oBSS it shall return the LCLS 
Configuration Change Request Acknowledge with a LCLS Configuration Change Result IE indicating success to the 
succeeding node. 

If the oMSC Server receives LCLS -ESS -Status indicating that the oBSS does not support the requested LCLS- 
Configuration then the oMSC Server shall return the LCLS Configuration Change Request Acknowledge message to 
the succeeding node with a LCLS Configuration Change Result IE indicating that the request is rejected. 

14.6.2.3 tMSC Server 

A tMSC Server wishing to insert a tone or announcement towards the originating UE may signal LCLS Configuration 
Change Request message with LCLS Configuration Preference IE set to "Need Send Backward = yes". 

NOTE: The other LCLS -Configuration Preference IE settings remain unchanged. 

If the tMSC Server receives the LCLS -Configuration Change Request Acknowledge message with a LCLS 
Configuration Change Result IE indicating acceptance of the requested LCLS Configuration change then it shall 
proceed to insert its tone or announcement as per a normal call handling. Otherwise, if the received LCLS 
Configuration Change Result IE indicates the requested LCLS Configuration change is rejected, the tMSC Server shall 
perform a MSC initiated LCLS break as described in sub-clause 7.2.1 and once the LCLS break is complete then begin 
applying the tone or announcement (on the completion of the tone or announcement LCLS may be re-established as 
described in sub-clause 7.3.1). 

If the LCLS Configuration Change Request was successful, on completion of the tone or announcement the tMSC 
Server may signal the LCLS - Configuration Change Request to the preceding node to return the LCLS configuration 
preference to the previously agreed value. 

If the tMSC Server wishes to insert a tone or announcement only towards its locally served UE it does not need to 
request any change to the LCLS configuration preferences in the Core Network and may send the LCLS-Connect- 
Control message to the tBSS containing the appropriate LCLS -Configuration IE settings as specified in Table 4.2.1.1 
and if supported by the tBSS it shall begin applying the tone or announcement. On completion of the tone or 
announcement the tMSC shall return the LCLS Configuration to the previous setting. 

If the tMSC Server receives LCLS -BSS -Status indicating that the tBSS does not support the requested LCLS- 
Configuration then the tMSC Server shall initiate LCLS Break towards the tBSS and preceding nodes, as described in 
sub-clause 7.2.1. On completion of the tone or announcement after LCLS Break the tMSC Server may may re-establish 
LCLS (with the previous LCLS Configuration) as described in sub-clause 7.3.1. 

If the tMSC Server receives the LCLS -Configuration Change Request message with the LCLS -Configuration 
Preference IE indicating "Need Send Forward = yes" it shall send LCLS-Connect-Control message containing the 
appropriate LCLS -Configuration IE settings as specified in Table 4.2.1.1 and if supported by the tBSS it shall return the 
LCLS Configuration Change Request Acknowledge message with a LCLS Configuration Change Result IE to the 
preceding node. 

If the tMSC Server receives LCLS -BSS -Status indicating that the tBSS does not support the requested LCLS- 
Configuration then the tMSC Server shall return the LCLS Negotiation Request Acknowledge message to the preceding 
node with a LCLS Configuration Change Result IE indicating that the request is rejected. 

14.6.2.4 BSS 

When the BSS receives a LCLS-Connect-Control message containing a LCLS -Configuration IE set to: 

"connected both- way in the BSS and send access DL from the Core Network" and it supports this configuration 
it shall return LCLS -BSS -Status indicating that the requested LCLS configuration is supported and from then on 
detect any incoming data packets and insert them in the stream towards the locally served UE. 

"connected both- way in the BSS and send access DL from the Core Network, block local DL" and it supports 
this configuration it shall return LCLS -BSS -Status indicating that the requested LCLS configuration is supported 
and it shall block the local DL path from the opposite call leg. When detecting user data packets from the Core 
Network, the BSS shall insert this user data in the stream towards the locally served UE. 
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"connected both- way in the BSS and bi-casted UL to the Core Network and send access DL from the Core 
Network" and it supports this configuration it shall return LCLS-BSS-Status indicating that the requested LCLS 
configuration is supported. When detecting user data packets from the Core Network, the BSS shall insert this 
user data in the stream towards the locally served UE and send UL user data to the Core Network. 

"connected both- way in the BSS and bi-casted UL to the Core Network and send access DL from the Core 
Network, block local DL" and it supports this configuration it shall block the local DL path from the opposite 
call leg and return LCLS-BSS-Status indicating that the requested LCLS configuration is supported. From then 
on it shall insert the data packets coming from the Core Network for that call leg in the stream towards the 
locally served UE and send UL user data to the Core Network. 

If the BSS does not support the requested LCLS -Configuration it shall return LCLS-BSS-Status indicating that the 
requested configuration is not supported; the LCLS configuration is kept as it was prior to receiving the LCLS-Connect- 
Control message. 

14.6.2.5 Example of Playing Mid-Call Announcement/Tone 



14.6.2.5.1 



Connection Model 



Figure 14.6.2.5.1.1 shows the network model where the iMSC server requests the iMGW to play the 
announcement/tone directly on the bearer termination T3 (used towards the preceding oMGW) from which the signal 
shall be sent towards the oUE. The bearer termination T4 is used for the bearer towards the succeeding tMGW (i.e. 
towards the tUE). Before the start of mid-call announcement/tone procedure the call was locally switched with the 
LCLS Configuration set to "connected both- way in the BSS". 



Control plane link which transmits signalling 

User plane link path through ON 

User plane link which transmits real user plane data within BSS and UEs 

Announcement / tone 



tUE 



oUE 




Connection Model 1: Locally switched call 
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tUE 



oUE 




14.6.2.5.2 



Announcement/ V oMGW 
tone 



Connection Model 2: Locally switched call, playing of Announcement/tone 
Figure 14.6.2.5.1.1: Connection Model, Mid-Call Announcement/tone 

Example Sequence 



Figure 14.6.2.5.2.1 shows the message sequence example for providing the oUE with an announcement/tone. In the 
example the iMSC server requests the iMGW to play an announcement/tone and to notify the announcement/tone 
completion. 
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Figure 14.6.2.5.2.1: Mid-Call Announcement/Tone Flow 

1. The iMSC server identifies that mid-call announcement/tone needs to be played towards the oUE. 

2. The iMSC server modifies the LCLS-Negotiation IE due to the announcement/tone it needs to play towards 
the oUE and sends LCLS Negotiation Request message towards the preceding node with the modified LCLS- 
Negotiation (request) IE indicating "Need Send Backward = yes". 

NOTE: Other values for the initially agreed LCLS-Negotiation IE for receive or send access are 
unmodified. 

3. The oMSC server informs the oBSS the user plane data needs to be provided to the oUE from the CN by 
sending the LCLS-Connect-Control message containing LCLS-Configuration IE set to "connected both-way 
in the BSS and send access DL from the Core Network". 

4. The oBSS confirms the requested configuration is enabled with the LCLS-Connect-Control Ack message. 

5. The oMSC server confirms the oBSS is prepared for the reception of announcement/tone by sending the 
LCLS Negotiation Request Acknowledge message with a Result Code IE indicating acceptance of the 
requested LCLS Negotiation change. 

6. At reception of the LCLS Negotiation Request Acknowledge message indicating that requested send access 
is enabled the iMSC server provides the iMGW with the announcement/tone identification and requests the 
iMGW to notify the announcement/tone completion using the Play Announcement or Send Tone procedure. 
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7. The iMGW notifies the iMSC server when the announcement/tone is completed using the Announcement 
Completed or Tone Completed procedure. 

8. The iMSC server signals to the preceding node the send access is not needed anymore by sending the LCLS 
Negotiation Request message with the LCLS -Negotiation (request) IE indicating "Need Send Backward = 
no". 

9. The oMSC server notifies the oBSS with the LCLS-Connect-Control message that no user plane data from 
the CN will be provided that is the LCLS -Configuration IE is set to "connected both- way in the ESS". 

10. The oBSS replies with the LCLS-Connect-Control Ack message indicating local switching with the 
requested LCLS configuration. 

11. The oMSC server confirms the oBSS has returned the LCLS connection to the status prior to the 
announcement/tone by sending the LCLS Negotiation Request Acknowledge message with a Result Code IE 
indicating acceptance of the requested LCLS Negotiation change. 

14.6.2.6 Examples with Uplink Bicasting of User Data 



14.6.2.6.1 



Connection Model 



Figure 14.6.2.6.1.1 shows the network model for the locally switched call with bicasting of user data to the Core 
Network where the oMSC server requests the oMGW to play the announcement/tone towards the originating UE. The 
dashed line in green represents call control signalling. Non-dotted lines represent the bearer carrying real user plane 
data: the solid line in turquoise represents the data from the originating UE and the solid line in yellow represents the 
data from the terminating UE. The solid line in blue represents an announcement played to the originating UE. The 
bearer termination Tl is used for the bearer towards the oBSS and the bearer termination T2 is used for the bearer 
towards the succeeding iMGW (i.e. towards the tUE). The announcement is applied directly on the bearer termination 
Tl from which the signal shall be sent towards the originating UE. 

If the oMSC server requires receiving UL data from the originating UE and the terminating UE and was sent a LCLS- 
Negotiation IE set to "Need_Receive_Backward = yes; Need_Receive_Forward = yes" to the succeeding node then 
when it needs to send the DL data to the originating UE the oMSC server will require from the oBSS to connect LCLS 
with bicasting UL and with DL send access and to block local DL. Connection model 2a is applied when the oBSS 
supports the required LCLS configuration and the announcement is played towards the originating UE. 

If the oMSC server requires receiving UL data from the originating UE and the terminating UE but was sent LCLS- 
Negotiation IE set to "Need_Receive_Backward = yes, Need_Receive_Forward = no" to the succeeding node and was 
received the LCLS -Negotiation IE set to "Need_Receive_Forward = no" then it may configure its oMGW to isolate the 
access side termination (Tl) from the network side termination (T2). When the oMSC server needs to send the DL data 
to the originating UE it requests the oBSS to connect LCLS with bicasting UL and with DL send access. Connection 
model 2b applies when the oBSS supports the required LCLS configuration and then the oBSS inserts the 
announcement from the Core Network towards the originating UE. 
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Connection Model 1 : Locally switched call with bicasting of user data to CN 
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tUE 



oue; 




Connection Model 2a: Locally Switched Call with Bicasting of User Data to CN and with Blocked 

Local DL Data, Playing of Announcement/tone 



tUE 



oUE 




Connection Model 2b: Locally Switched Call with Bicasting of User Data to CN and Isolation of 

Access Side, Playing of Announcement/tone 

Figure 14.6.2.6.1.1: Connection Model, LCLS with UL Bicasting and Mid-Call Announcement/tone 



14.6.2.6.2 



Example Sequences with Uplink Bicasting of User Data 



Figure 14.6.2.6.2.1 shows the message sequence example for providing the originating UE with an announcement/tone. 
In the example the call is locally switched with bicasting of user data to the Core Network. The oMSC server requests 
the oBSS to connect LCLS with bicasting UL and with DL send access and to block local DL. The oMSC server 
requests the oMGW to play an announcement/tone and to notify the announcement/tone completion. 
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Figure 14.6.2.6.2.1: Mid-Call Announcement/Tone Flow with Block Local Data Request 

1. The oMSC server identifies that mid-call announcement/tone needs to be played towards the oUE. 

2. The oMSC server informs the oBSS the user plane data needs to be provided to the oUE from the CN by 
sending the LCLS-Connect-Control message containing LCLS-Configuration IE set to "connected both-way 
in the BSS and bi-casted UL to the Core Network and send access DL from the Core Network, block local 
DL". 

3. The oBSS confirms the requested configuration is enabled with the LCLS-Connect-Control Ack message. 

4. At reception of the LCLS-Connect-Control Ack message indicating that requested LCLS configuration is 
supported the oMSC server provides the oMGW with the announcement/tone identification and requests the 
oMGW to notify the announcement/tone completion using the Play Announcement or Send Tone procedure. 

5. The oMGW notifies the oMSC server when the announcement/tone is completed using the Announcement 
Completed or Tone Completed procedure. 

6. The oMSC server notifies the oBSS with the LCLS-Connect-Control message that DL send access is no 
longer needed that is the LCLS-Configuration IE is set to "connected both-way in the BSS and 
bi-casted UL to the Core Network" . 

7. The oBSS replies with the LCLS-Connect-Control Ack message indicating local switching with the 
requested LCLS configuration. 
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14.6.2.6.3 



Example Sequence when Access Side Termination is isolated in MGW 



Figure 14.6.2.6.3.1 shows the message sequence example for providing the originating UE with an announcement/tone. 
Since other CN nodes didn't requested receiving UL data from the originating UE the oMSC server may configure its 
oMGW to isolate the access side termination from the network side termination. In the example the oMSC server 
requests the oMGW to play an announcement/tone and to notify the announcement/tone completion. 
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Figure 14.6.2.6.3.1 : Mid-Call Announcement/Tone Flow when Access Side Termination is Isolated in 

MGW 

1 . The oMSC server identifies that mid-call announcement/tone needs to be played towards the oUE. 

2. If the LCLS negotiation indicated that any succeeding node does not require the UL data from the oUE then 
the oMSC server requests the oMGW to isolate the access side termination Tl from the network side 
termination T2. 

NOTE 1 : the MOVE command (Isolate Bearer termination procedure) is not required if Tl has been 
already moved from the context oC during the call establishment procedure. 

NOTE 2: The MSC server can also use the Change Through-Connection procedure and requests the MGW 
to change the through-connection of the bearer to inactive instead of using of the Isolate Bearer 
termination procedure, see 3GPP TS 23.205 [2]. 
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3. The oMSC server informs the oBSS the user plane data needs to be provided to the oUE from the CN by 
sending the LCLS-Connect-Control message containing LCLS -Configuration IE set to "connected both-way 
in the BSS and bi-casted UL to the Core Network and send access DL from the Core Network". 

4. The oBSS confirms the requested configuration is enabled with the LCLS-Connect-Control Ack message. 

5. At reception of the LCLS-Connect-Control Ack message indicating that requested LCLS configuration is 
supported the oMSC server provides the oMGW with the announcement/tone identification and requests the 
oMGW to notify the announcement/tone completion using the Play Announcement or Send Tone procedure. 

6. The oMGW notifies the oMSC server when the announcement/tone is completed using the Announcement 
Completed or Tone Completed procedure. 

7. The oMSC server notifies the oBSS with the LCLS-Connect-Control message that DL send access is no 
longer needed that is the LCLS -Configuration IE is set to "connected both-way in the BSS and bi-casted UL 
to the Core Network" . 

8. The oBSS replies with the LCLS-Connect-Control Ack message indicating local switching with the 
requested LCLS configuration. 

9. The oMSC server may send to the oMGW request to move the access side termination Tl to context oC with 
the network side termination T2. 

NOTE 3: Steps 9 is optional and not needed if step 2 is not performed. 

NOTE 4: If the MSC server has used the Change Through-Connection procedure in step 2 instead of the 
Isolate Bearer termination procedure then the MSC server will use the Change Through- 
Connection procedure to request the MGW to change the through-connection of the bearer to be 
both-way through-connected. 

14.7 Global Text Telephony 

LCLS shall not be allowed for Global Text Telephony. 

14.8 Emergency Calls 

LCLS shall not be allowed for Emergency Calls. 

1 4.9 Subscriber and equipment trace 

No impact. There are no LCLS related requirements for Subscriber and Equipment Trace. 

14.10 Customized Alerting Tone 

14.10.1 Audio CAT 

No impact. There are no LCLS related requirements for Audio CAT. 

14.10.2 Multimedia CAT 

LCLS shall not be allowed for multimedia calls. 

14.1 1 Tandem Free Operation (TFO) 

No impact. There are no LCLS related requirements for Tandem Free Operation (TFO). 

LCLS may be activated for calls that use TFO, but the TFO operation is interrupted for the time that the call is locally 
switched. If LCLS is broken in the middle of a call, the TFO operation may resume, if still applicable. 
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14.12 Transcoder Free Operation (TrFO) 

No impact. There are no LCLS related requirements for Transcoder Free Operation (TrFO). 



14.13 CS Data Calls 



LCLS shall not be allowed for CS Data Calls. 



14.14 RIP Multiplexing 

No impact. There are no LCLS related requirements for RTP Multiplexing. 



15 Tunnelling 



The tunnelling procedures shall be applied in accordance with 3GPP TS 23.205 [2]. 



1 6 Messages/Procedures and their contents 

16.1 Messages between (G)MSC servers 

16.1.1 General 

The BICC messages between (G)MSC servers on Nc interface are specified in 3GPP TS 23.205 [2]. The SIP methods 
and corresponding responses that shall be supported between (G)MSC servers on Nc interface are specified in 
3GPP TS 29.231 [10]. The LCLS related information exchanged in these messages and encapsulated in the 
corresponding SIP messages is specified below and in 3GPP TS 29.205 [6]. 

The MAP messages used for inter-MSC handover between Anchor and Target MSC-Server (E-interface) are specified 
in 3GPP TS 23.205 [2] and 3GPP TS 23.009[9]. The LCLS related information exchanged in these messages is 
specified below and in 3GPP TS 29.002 [12]. 

16.1.2 Initial Address 

Table 16.1.2.1 indicates the LCLS related information which is exchanged between the MSC servers in the Initial 
Address (BICC: lAM or SIP-I: INVITE request with encapsulated ISUP lAM) message. Only the Information Elements 
required by LCLS are shown. 

Table 16.1.2.1: LCLS related information in Initial Address message 



Message 


Message 
direction 


Information element 
name 


Information 
element 
required 


Information element description 


Initial Address 

(BICC: lAM or 

SIP-I: INVITE 

[lAM]) 


Forward 


Global Call Reference 


C 


This information element identifies the call. 
This information element shall be included 
when LCLS is supported in the core network. 


LCLS-Negotiation 
Request 


C 


This information element indicates the initial 
negotiation request and LCLS permissions. 
This information element shall be included 
when LCLS is supported in the core network. 


LCLS-Configuration- 
Preference 


c 


This information element indicates the LCLS 
configuration preference while LCLS is 
established. This information element shall 
be included when LCLS is supported in the 
core network. 
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16.1.3 Answer 

Table 16.1.3.1 indicates the LCLS related information which is exchanged between the MSC servers in the Answer 
(BICC: ANM or SIP-I: 200 OK final response to initial INVITE request with encapsulated ANM) message. Only the 
Information Elements required by LCLS are shown. 

Table 16.1.3.1: LCLS related information in Answer message 



Message 


Message 
direction 


Information element 
name 


Information 
element 
required 


Information element description 


Answer 
(BICC: ANM or 
SIP-I: 200 OK- 
INVITE [ANM]) 


Backward 


LCLS-Status 


C 


This information element identifies the LCLS 
connection status. This information element 
shall be included when LCLS is negotiated in 
the core network. 



16.1.4 Bearer and Codec Information 

Table 16.1.4.1 indicates the LCLS related information which is exchanged between the MSC servers in the Bearer and 
Codec Information (BICC: APM) message. Only the Information Elements required by LCLS are shown. 

Table 16.1.4.1: LCLS related information in Bearer and Codec Information message 



Message 


Message 
direction 


Information element 
name 


Information 
element 
required 


Information element description 


Bearer and Codec 
Information 
(BICC: APM 


Backward 


LCLS-Negotiation 
Response 





This information element indicates the initial 
negotiation response. This information 
element shall be included when the APM is 
related to LCLS negotiation in Bearer and 
Codec Information messages and LCLS is 
supported in the core network. 


LCLS-Configuration- 
Preference 


C 


This information element indicates the LCLS 
configuration preference while LCLS is 
established. This IE shall be included if the 
LCLS-Negotiation Response is included. 



16.1.5 Backward LCLS Negotiation 

Table 16.1.5.1 indicates the LCLS related information which is exchanged between the MSC servers in the LCLS 
Negotiation (BICC: APM; SIP-L 183 Session Progress provisional response with encapsulated APM) message or in the 
Address Complete (BICC: ACM; SIP-I: 183 Session Progress provisional response with encapsulated ACM) message 
or in the Call Progress (BICC: CPG; SIP-I: 183 Session Progress provisional response with encapsulated CPG) 
message. Only the Information Elements required by LCLS are shown. 

Table 16.1.5.1: LCLS related information in the LCLS Negotiation message 



Message 


Message 
direction 


Information element 
name 


Information 
element 
required 


Information element description 


LCLS Negotiation 

(BICC: APM; 

SIP-I: 183 Session 

Progress [APIVI]) 


Backward 


LCLS-Negotiation 
Response 


M 


This information element indicates the initial 
negotiation response. 


LCLS-Configuration- 
Preference 


M 


This information element indicates the LCLS 
configuration preference while LCLS is 
established. 
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Table 16.1.5.2: LCLS related information in the Address Complete message 



Message 


Message 
direction 


Information element 
name 


Information 
element 
required 


Information element description 


Address Complete 

(BICC: ACM; 

SIP-I: 183 Session 

Progress [ACM]) 


Backward 


LCLS-Negotiation 
Response 





This information element indicates the initial 
negotiation response. 


LCLS-Configuration- 
Preference 


C 


This information element indicates the LCLS 
configuration preference while LCLS is 
established. This IE shall be included if the 
LCLS-Negotiation Response is included. 



Table 16.1.5.3: LCLS related information in the Call Progress message 



Message 


Message 
direction 


Information element 
name 


Information 
element 
required 


Information element description 


Call Progress 

(BICC: CPG; 

SIP-I: 183 Session 

Progress [CPG]) 


Backward 


LCLS-Negotiation 
Response 





This information element indicates the initial 
negotiation response. 


LCLS-Configuration- 
Preference 


C 


This information element indicates the LCLS 
configuration preference while LCLS is 
established. This IE shall be included if the 
LCLS-Negotiation Response is included. 



16.1.6 Change of LCLS Configuration 

Table 16.1.6.1 indicates the LCLS related information which is exchanged between the MSC servers in the LCLS 
Configuration Change Request (BICC: APM or SIP-L INFO request with encapsulated APM) messages. 

Table 16.1.6.1: LCLS related information in the LCLS Configuration Change Request message 



Message 


Message 
direction 


Information element 
name 


Information 
element 
required 


Information element description 


LCLS 
Configuration 

Change Request 
(BICC: APM or 

SIP-I: INFO [APM] 


Both 


LCLS-Configuration- 
Change Request 


M 


This information element indicates a request 
to change the requested LCLS configuration 
preference. 


LCLS-Configuration- 
Preference 


M 


This information element indicates the LCLS 
configuration preference to be changed to. 


LCLS 
Configuration 

Change Request 
Acknowledge 
(BICC: APM or 

SIP-I: INFO [APM] 


Both 


LCLS-Configuration- 
Change Result 


M 


This information element indicates if the 
LCLS Configuration Change Request is 
accepted or not. 


LCLS-Configuration- 
Preference 


M 


This information element has the same value 
as in LCLS Configuration Change Request. 



16.1.7 LCLS Status update 

Table 16.L7.1 indicates the LCLS related information which is exchanged between the MSC servers in the LCLS 
Status update (BICC: APM or SIP-L INFO request with encapsulated ISUP APM) message. 

Table 16.1.7.1: LCLS related information in LCLS Status update message 



Message 


Message 
direction 


Information element 
name 


Information 
element 
required 


Information element description 


LCLS Status 

update 

(BICC: APM or 

SIP-I: INFO 

[APM]) 


Both 


LCLS-Status 


M 


This information element indicates the LCLS 
connection status. This information element 
shall be included when LCLS connection 
status has changed in the BSS. 
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16.1.8 Change of LCLS Status 

Table 16.1.8.1 indicates the LCLS related information which is exchanged between the MSC servers in the LCLS 
Status Change Request (BICC: APM or SIP-L INFO request with encapsulated ISUP APM) messages. 

Table 16.1.8.1: LCLS related information in LCLS Status Change Request message 



Message 


Message 
direction 


Information element 
name 


Information 
element 
required 


Information element description 


LCLS Status 

Change Request 

(BICC: APM or 

SIP-I: INFO 

[APM]) 


Both 


LCLS-Status-Change 


M 


This information element indicates a request 
to change the LCLS connection status in the 
BSS. 


LCLS Status 

Change Request 

Acknowledge 

(BICC: APM or 

SIP-I: INFO 

[APM]) 


Both 


LCLS-Status-Change 


M 


This information element has the same value 
as in the LCLS-Status-Change-Request 
message. 


Result Code 


M 


This information element indicates if the 
LCLS Status Change request is accepted or 
not. 
NOTE 


NOTE: A request to break LCLS shall not be rejected. 



16.1 .9 MAP_PREPARE_HANDOVER Request 

Table 16.1.9.1 indicates the LCLS related information which is exchanged between the Anchor MSC-Server and the 
Target MSC-Server (E-interface) in the MAP_PREPARE_HANDOVER Request message. 

Table 16.1.9.1: LCLS related information in MAP-Prepare-Handover Request message 



Message 


Message 
direction 


Information element 
name 


Information 
element 
required 


Information element description 


MAP PREPARE 

HANDOVER 

Request 


From 
Anchor 
MSC- 
Server to 
Target 
MSC- 
Server 


LCLS OCR 


C 


This information element identifies the call. 
This information element shall be included 
when LCLS is supported in the core network. 


LCLS-Negotiation 
Request 


C 


This information element indicates request for 
LCLS. This information element shall be 
included when LCLS is supported in the core 
network. 


LCLS-Configuration- 
Preference 


c 


This information element indicates the LCLS 
configuration preference while LCLS is 
established. This information element shall 
be included when LCLS is supported in the 
core network. 



1 6.2 Procedures between (G)MSC server and MGW 

The (G)MSC server and MGW procedures shall be performed in accordance with 3GPP 23.205 [2] for a BICC based 
CS core network and in accordance with 3GPP TS 23.231 [3] for a SIP-I based CS core network. 

1 6.3 Messages between MSC server and BSS 
16.3.1 General 

The procedures used on the Base Station System (BSS) to Mobile-services Switching Centre (MSC) interface for 
control of GSM services are specified in 3GPP TS 48.008 [7]. The LCLS related information exchanged in these 
procedures is specified below. 
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16.3.2 Assignment Procedure between MSC-Server and BSS 

Table 16.3.2.1 indicates the LCLS related information which is exchanged between the MSC server and the BSS in the 
BSSMAP Assignment Procedure. Only the Information Elements required by LCLS are shown. 

Table 16.3.2.1: LCLS related information in Assignment Procedure 



Procedure 


Message 
direction 


Information element 
name 


Information 
element 
required 


Information element description 


Assignment 
Request 


From 
MSC-S 


Global Call Reference 


C 


This information element identifies the call. 
This information element shall be included if 
local switching is requested by the MSC 
server. 


LCLS-Configuration 


C 


This information element indicates the LCLS 
connection preference which shall persist in 
the BSS while LCLS is established. This 
information element shall be included if local 
switching is requested by the MSC server. 


LCLS-Connection- 
Status-Control 


c 


This information element indicates to BSS 
whether it is permitted to locally through- 
connect the call. This information element 
shall be included if local switching is 
requested by the MSC server and when the 
Assignment Request message is sent after 
Answer. 


LCLS-Correlation-Not- 
Needed 





This information element indicates to the BSS 
that call correlation is not needed. 
This information element shall be sent if the 
MSC-Server has detected that the call is not 
an Intra-BSS call or an Intra-network call. 


Assignment 
Complete 


From BSS 


LCLS-BSS-Status 


c 


This information element notifies CN of the 
LCLS connection status in the BSS. This 
information element shall be included if BSS 
supports LCLS and both Global Call 
Reference IE and LCLS-Configuration IE 
were included in the ASSIGNMENT 
REQUEST message. 



16.3.3 Handover Request Procedure between MSC-Server and BSS 

Table 16.3.3.1 indicates the LCLS related information, which is exchanged between the MSC server and the BSS in the 
BSSMAP Handover Request Procedure. Only the Information Elements required by LCLS are shown. 
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Table 16.3.3.1: LCLS related information in Handover Request Procedure 



Procedure 


Message 
direction 


Information element 
name 


Information 
element 
required 


Information element description 


Handover Request 


From 
MSC-S 


Global Call Reference 


C 


This information element identifies the call. 
This information element shall be included if 
local switching is requested by the MSC 
server. 


LCLS-Connection- 
Status-Control 


C 


This information element indicates to BSS 
whether it is permitted to locally through- 
connect the call. This information element 
shall be included if local switching is 
requested by the MSC server. 


LCLS-Configuration 


c 


This information element indicates the LCLS 
connection preference which shall persist in 
the BSS while LCLS is established. This 
information element shall be included if local 
switching is requested by the MSC server. 


Handover Request 
Ackknowledge 


From BSS 


LCLS-BSS-Status 


c 


This information element notifies CN of the 
LCLS connection status in the BSS. This 
information element shall be included if BSS 
supports LCLS and Global Call Reference IE, 
LCLS-Configuration IE and LCLS- 
Connection-Status-Control IE were included 
in the HANDOVER REQUEST message. 



16.3.4 Handover Complete Procedure between MSC-Server and BSS 

Table 16.3.4.1 indicates the LCLS related information, which is exchanged between the MSC server and the BSS in the 
BSSMAP Handover Complete Procedure. Only the Information Elements required by LCLS are shown. 

Table 16.3.4.1: LCLS related information in Handover Request Procedure 



Procedure 


Message 
direction 


Information element 
name 


Information 
element 
required 


Information element description 


Handover 
Complete 


From BSS 


LCLS-BSS-Status 


C 


This information element notifies CN of the 
LCLS connection status in the BSS. This 
information element shall be included if BSS 
supports LCLS and if local switching was 
previously requested for this call leg by the 
MSC server. 



16.3.5 Handover Performed Procedure between MSC-Server and BSS 

Table 16.3.5.1 indicates the LCLS related information, which is exchanged between the MSC server and the BSS in the 
BSSMAP Handover Performed Procedure. Only the Information Elements required by LCLS are shown. 
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Table 16.3.5.1: LCLS related information in Handover Request Procedure 



Procedure 


Message 
direction 


Information element 
name 


Information 
element 
required 


Information element description 


Handover 
Performed 


From BSS 


LCLS-BSS-Status 


C 


This information element notifies CN of the 
LCLS connection status in the BSS. This 
information element shall be included if BSS 
supports LCLS and if local switching was 
previously requested for this call leg by the 
MSC server. 



16.3.6 Internal Handover Command Procedure between MSC-Server and 
BSS 

Table 16.3.6.1 indicates the LCLS related information, which is exchanged between the MSC server and the BSS in the 
BSSMAP Internal Handover Command Procedure. Only the Information Elements required by LCLS are shown. 

Table 16.3.6.1: LCLS related information in Internal Handover Command Procedure 



Procedure 


Message 
direction 


Information element 
name 


Information 
element 
required 


Information element description 


Internal Handover 
Command 


From 
MSC-S 


LCLS-Connection- 
Status-Control 


C 


This information element indicates to BSS 
whether it is permitted to locally through- 
connect the call. This information element 
shall be included if local switching is 
requested by the MSC server, and LCLS- 
Connection-Status-Control indicating 
"Connect" has not previously been sent to the 
BSS for this particular call leg. 



16.3.7 LCLS Connection Procedure between MSC-Server and BSS 

Table 16.3.7.1 indicates the LCLS Connection Procedure and related information, which is exchanged between the 
MSC server and the BSS. Only the Information Elements required by LCLS are shown. 

Table 16.3.7.1: LCLS Connection Procedure between MSC-Server and BSS 



Procedures 


Message 
direction 


Information element 
name 


Information 
element 
required 


Information element description 


LCLS-Connect- 
Control 


From 
MSC-S 


LCLS-Connection- 
Status-Control 





This information element indicates to BSS 
whether it is permitted to locally through- 
connect the call. 


LCLS-Configuration 





This information element indicates the LCLS- 
Configuration. 


LCLS Connect 
Control Ack 


From BSS 


LCLS-BSS-Status 


M 


This information element notifies CN of the 
LCLS connection status in the BSS. 



16.3.8 LCLS Notification Procedure between IVISC-Server and BSS 

Table 16.3.8.1 indicates the LCLS Notification Procedure and related information, which is exchanged between the 
MSC server and the BSS. Only the Information Elements required by LCLS are shown. 
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Table 16.3.8.1: LCLS Notification Procedures between MSC-Server and BSS 



Procedures 


Message 
direction 


Information element 
name 


Information 
element 
required 


Information element description 


LCLS-Notification 


From BSS 


LCLS-BSS-Status 


C 


This information element notifies CN of the 
LCLS connection status in the BSS. This 
information element shall be included when 
BSS changes the LCLS connection status. 


LCLS-Break-Request 


C 


This information element indicates if the 
LCLS break request is ordered from CN. This 
information element shall be included when 
BSS requests to disconnect local switching. 


NOTE: Only one of those IE shall be present in the LCLS Notification message. 



17 



Bearer Redirect 



Bearer Redirect mechanisms within BICC based CS core network may be appHed as specified in 3GPP TS 23.205 [2]. 
Bearer Redirect is not supported within SIP-I based CS core network, see 3GPP TS 23.231 [3]. 

1 8 (G)MSC MOW Tandeming 

It is FFS the impacts to (G)MSC MOW Tandeming procedure as specified in 3GPP TS 23.205 [2]. 



19 



Timers 



The Timers as defined for a BICC based CS Core Network shall be applied as defined in 3GPP TS 23.205 [2]. 
The Timers as defined for a SIP-I based CS Core Network shall be applied as defined in 3GPP TS 23.231 [3]. 



20 Multiple Realms 



The principles for multiple IP realms shall be applied as defined in 3GPP TS 23.205 [2]. 
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Annex A (informative): 

Case studies for LCLS Negotiation 



Annex A provides examples of LCLS negotiation in the CN and LCLS configuration in the BSS. The examples also 
illustrate optional isolation scenarios and the change of the initial set of preferences during LCLS negotiation. 

A.1 oMSC LCLS-Negotiation handling when receiving UL bicast and 

sending DL data 

Case study 1 : If the oMSC server requires receiving UL data from the terminating UE and sending DL data to the 
originating UE then it shall perform one of the following: 

- send LCLS-Negotiation (request) set to "LCLS -Not- Alio wed" or; 

- send LCLS-Negotiation (request) set to "Need_Receive Backward = Yes, Need_Send_Backward = Yes", set 
LCLS -Configuration IE to "connected both- way in the BSS and send access DL from the Core Network, block 
local DL" on the originating call leg (as shown in Figure X.Ll). If the BSS supports this configuration then 
LCLS will be allowed; otherwise LCLS will not be permitted. 

NOTE 1: On the terminating leg the LCLS configuration IE is set to "connected both- way in the BSS and bi-cast 
UL to the Core Network" by the tMSC. 
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Figure A.1 .1 : oMSC requesting UL data from tUE plus sending DL data to oUE 

Case study 2: If the oMSC server requires receiving UL data from the originating UE it shall either: 

send LCLS-Negotiation (request) set to "Need_Receive Forward = Yes" and set LCLS-Configuration IE to 
"connected both-way in the BSS and bi-cast UL" on the originating call leg after confirmation (as shown in 
Figure XL2). If the BSS supports this configuration then LCLS will be allowed; otherwise LCLS will not be 
permitted. The data in the forward direction is passed to the tBSS due to the result of LCLS negotiation process 
on the originating call leg. 

NOTE 2: On the terminating leg the LCLS configuration IE is set to "connected both-way in the BSS" if LCLS 

connection preference that is negotiated through the Core Network only requires UL data from the oUE 
as shown in Figure XL2. For the requested LCLS configuration on the terminating call leg the tBSS does 
not expect to receive any user data from the Core Network but is specified to discard if received. 



ETSI 



3GPP TS 23.284 version 10.3.0 Release 10 



179 



ETSI TS 123 284 VI 0.3.0 (2012-01) 



LCLS-Negotiation 
\ (Need Receive 



UL data 
requested 
from oUE 



r 
I 




<»^i^^> j^^^^^^^ ^^^^ ^^^^^^^^y V^ )> !• 



MGW-0 



MGW-I 



User Plane (connection) 



Local User Plane Data BSS-1/ 
BSS-2 





UE-o 



UE-t 



Figure A.1.2: oMSC requesting UL data from oUE indicated in LCLS-Negotiation 

In order to avoid the forwarding of the data in the forward direction to the tMGW the oMSC can send LCLS- 
Negotiation (request) to the succeeding node set to "Need_Receive_Forward = No" and if it does not receive 
"Need_Receive_Forward = Yes" in the LCLS-Negotiation (response) then it may configure its MGW to isolate 
the network side termination from the access side termination (as shown in Figure X.1.3). 



LCLS-Negotiation 
(Need Receive 




Option with 
Need_Receive_Forward = No: 
Isolate access side termination 



UE-o 



UE-t 



from network side termination 

Figure A.1.3: oMSC requesting UL data from oUE not indicated in LCLS-Negotiation 

If the initial setting "Need_Receive_Forward = No" is overwritten by a succeeding Core Network node and the 
oMSC server receives "Need_Receive_Forward = Yes" in the LCLS-Negotiation (response) then it shall 
configure its MGW to be bothway through-connected (as shown in Figure X.L4). 



ETSI 



3GPP TS 23.284 version 10.3.0 Release 10 



180 



ETSI TS 123 284 VI 0.3.0 (2012-01) 



LCLS-Negotiation 
(Need Receive 



UL data 
requested from 
oUE by oMSC 
& (iMSC and/or 

tMSC) 




Result of LCLS-Negotiation 

Need_Receive_Forward = yes 

olVIGW bothway through 

connected 



UE-o 



UE-t 



Figure A.1.4: UL data requested from oUE by iMSC/tMSC, oMGW bothway through-connected 

Case study 3: If the oMSC server receives a LCLS-Negotiation (response) set to "Need_Send_Backward = Yes" and 
"Need_Receive_Backward = Yes" (succeeding node of the oMSC server requires to send data to the oUE and to receive 
data from the tUE) then it shall perform one of the following: 

- send an LCLS-Negotiation (request) set to "LCLS -Not- Alio wed" or; 

- set the LCLS -Configuration IE to "connected both- way in the BSS and send access DL from the Core Network, 
block local DL" on the originating leg (as shown in Figure X.L5). 

If the BSS supports this configuration then LCLS will be allowed and the requested LCLS configuration will be 
confirmed; otherwise LCLS will not be permitted. 

NOTE 3: On the terminating leg the LCLS configuration IE is set to "connected both- way in the BSS and bi-cast 
UL to the Core Network" by the tMSC. 
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Figure A.1.5: iMSC requesting UL data from tUE plus sending DL data to oUE 



tMSC LCLS-Negotiation handling when receiving UL bicast and 
sending DL data 



Case study 1: If the tMSC server receives LCLS-Negotiation (request) with "Need_Send_Forward = Yes" and 
"Need_Receive_Forward = Yes" then it shall either: 

- return LCLS-Negotiation (response) set to "LCLS -Not- Alio wed" or; 

- return LCLS-Negotiation (response) with value "Need_Send_Forward = Yes" and "Need_Receive_Forward = 
Yes" and set LCLS-Configuration IE to "Send Access DL, block local DL" (as shown in Figure X.2.1). If the 
BSS supports this configuration then LCLS will be allowed; otherwise LCLS will not be permitted. 

NOTE 1: On the originating leg the LCLS configuration IE is set to "connected both-way in the BSS and bi-cast 
UL to the Core Network" by the oMSC. 
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Figure A.2.1 : iMSC requesting UL data from oUE and sending DL data to tUE 

Case study 2: If the tMSC server requires sending DL data to the terminating UE and receives LCLS-Negotiation 
(request) with "Need_Receive_Forward = Yes" and "Need_Send_Forward = No" during a LCLS negotiation request it 
shall either: 

- return LCLS-Negotiation (response) set to "LCLS -Not- Alio wed" or; 

- set LCLS -Configuration IE to "connected both- way in the BSS and send access DL", return LCLS-Negotiation 
(response) with value "Need_Send_Forward = No" and "Need_Receive_Forward = Yes" and configure its 
Access MGW to isolate the network side termination from the access side termination when LCLS is established 
in order to avoid the forwarding of data from the oMGW/iMGW in the forward direction (as shown in Figure 

X.2.2), or; 

NOTE 2: On the originating leg the LCLS configuration IE is set to "connected both- way in the BSS and bi-cast 
UL to the Core Network" by the oMSC. 
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Figure A.2.2: iMSC requesting UL data from oUE and tMSC requesting DL data to tUE: option isolate 
access side termination from network side termination 

- return LCLS-Negotiation (response) with value "Need_Send_Forward = Yes" and "Need_Receive_Forward = 
Yes" and set LCLS -Configuration IE to "Send Access DL, block local DL" (as shown in Figure X.2.3). If the 
BSS supports this configuration then LCLS will be allowed; otherwise LCLS will not be permitted. 

NOTE 3: On the originating leg the LCLS configuration IE is set to "connected both- way in the BSS and bi-cast 
UL to the Core Network" by the oMSC. 
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Figure A.2.3: iMSC requesting UL data from oUE and tMSC requesting DL data to tUE: option send 

Access DL, block local DL 

Case study 3: If the tMSC server requires receiving UL data from the terminating UE and it receives LCLS-Negotiation 
(request) with "Need_Receive_Backward = No" (as shown in Figure X.2.4) during a LCLS negotiation request then it 
shall either: 

- set LCLS -Configuration IE to "connected both- way in the BSS and bi-cast UL" and return LCLS-Negotiation 
(response) with "Need_Receive Backward = Yes" or; 

- set LCLS -Configuration IE to "connected both- way in the BSS and bi-cast UL", return LCLS-Negotiation 
(response) with "Need_Receive Backward = No" and configure its MGW to isolate its access side termination 
from the network side termination in order to avoid the forwarding of data in the backward direction through the 

CN. 
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Figure A.2.4: tMSC requires DL data from tUE: option isolate access side termination from network 

side termination 
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